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TOPICS  IN  PERFORMANCE  EVALUATION 


Preface 

In  July,  1977,  we  published  CSRG-83,  "Topics  in  Queueing  Network  Model¬ 
ing",  containing  seven  papers  by  members  of  Project  SAM,  in  the  Computer  Sys¬ 
tems  Research  Group,  University  of  Toronto.  Now,  two  years  later,  six  papers 
covering  some  of  Project  SAM's  recent  work  are  gathered  together  in  CSRG-100, 
"Topics  in  Performance  Evaluation".  This  preface  highlights  the  results  of  each 
paper. 

The  field  of  exact,  efficient  computational  algorithms  continues  to  attract 
the  attention  of  researchers.  In  the  first  paper,  John  Zahorjan  returns  to  the 
first  computational  technique,  the  convolution  algorithm.  He  first  presents  an 
intuitive  explanation  of  the  convolution  algorithm,  making  it  easier  to  under¬ 
stand  than  the  mathematics  would  indicate.  He  then  presents  a  simple  generali¬ 
zation  of  the  known  algorithm  that  extends  it  to  any  closed  queueing  network 
that  can  be  shown  to  have  a  product  form  solution.  Two  types  of  networks  that 
receive  particular  attention  are  the  class  change  networks  and  Lam-type  net¬ 
works,  having  certain  population  size  constraints. 

Another  area  of  recent  intense  activity  is  operational  analysis.  In  the 
second  paper,  Ken  Sevcik  and  Maria  Klawe  compare  operational  analysis  and 
stochastic  analysis  from  a  technical  (i.e.,  non-emotional)  viewpoint.  They  first 
discuss  the  two  approaches  separately,  discussing  assumptions,  parametric  set¬ 
tings,  validation,  and  prediction.  The  approaches  are  then  compared  using 
three  examples,  which  leads  to  a  discussion  of  the  relative  strengths  and 
weaknesses  of  operational  analysis  and  stochastic  analysis. 

Workload  characterization  is  the  general  area  investigated  by  Tony  Chu  in 
the  third  paper.  His  focus  is  a  comparison  of  clustering  techniques  in  the  com¬ 
puter  workload  environment.  The  paper  describes  the  general  theory  and  basic 
approaches  of  cluster  analysis,  and  then  presents  and  evaluates  six  simple  algo¬ 
rithms  using  actual  workload  data.  Criteria  for  comparing  the  algorithms  in¬ 
clude  computational  requirements,  the  clusters,  generated,  and  the  workload  in¬ 
sight  provided.  He  concludes  that  cluster  analysis  is  a  useful  approach  for  iden¬ 
tifying  the  component  job  groups  of  a  workload. 

Martin  Kienzle  and  Ken  Sevcik  survey  nineteen  case  studies  involving  the 
use  of  queueing  network  models  to  investigate  actual  computer  systems,  in  the 
fourth  paper.  They  first  classify  queueing  network  models  according  to  six  pro¬ 
perties.  After  reviewing  measurement  tools  briefly,  they  provide  a  useful  review 
of  parameter  estimation  methods,  discussing  such  important  issues  as  handling 
CPU  overhead  and  determining  I/O  service  times.  They  summarize  the  case  stu¬ 
dies  reviewed  in  the  paper  in  a  handy  tabular  form. 


IV 


Queueing  network  modeling  of  an  IMS /MVS  data  base/data  communica¬ 
tions  system  is  the  subject  of  the  fifth  paper,  by  Lenny  Freilich.  The  author  be¬ 
gins  with  a  useful  review  of  the  MVS  environment,  the  IMS  environment,  and  the 
performance  monitors  available  in  such  environments.  He  then  presents  the 
results  of  a  single  class  model,  which  validates  outstandingly  welL  Multiple  class 
results  follow,  but  they  do  not  validate  as  well,  due  to  the  problem  of  obtaining 
sufficient  class-based  data.  The  author  discusses  the  predictive  abilities  of  both 
types  of  models. 

In  the  final  paper,  Ken  Sevcik  and  Isi  Mitrani  investigate  the  trade-off 
between  centralized  and  decentralized  computing.  The  routing  of  workload, 
among  cooperating  on-site  processors  and  a  large,  centralized,  remote  proces¬ 
sor,  plays  an  important  role  in  the  trade-off.  In  addition  to  the  workload  routing 
flexibility,  they  also  consider  the  flexibility  of  allocating  processing  power  among 
the  sites  subject  to  a  fixed  budget.  Given  these  flexibilities,  they  consider  local 
and  global  optimization  of  job  performance.  Examples  are  given  to  illustrate  the 
techniques. 


This  report  comes  from  Project  SAM,  a  continuing  research  project  investi¬ 
gating  computer  system  performance,  with  special  emphasis  on  queueing  net¬ 
work  models.  The  work  of  Project  SAM  is  supported  in  part  by  operating  grants 
to  individual  faculty  members  from  the  Natural  Sciences  and  Engineering 
Research  Council.  1  would  like  to  thank  Inge  Weber  for  her  help  in  preparing  this 
report.  Special  thanks,  for  his  continuing  counsel,  inspiration,  and  friendship, 
go  to  Sam  Beaver. 
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Computational  Algorithms  for  Queueing  Networks 
with  Product  Form  Solutions 


John  Zahorjan 


Abstract 

This  paper  discusses  the  convolution  algorithms  for  the  solution  of  separ¬ 
able  queueing  networks.  We  first  present  an  intuitive  explanation  of  these  algo¬ 
rithms,  and  then  present  a  simple  generalization  that  extends  them  to  any 
closed  queueing  network  that  can  be  shown  to  have  a  product  form  solution. 
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L  Introduction 

Stochastic  queueing  network  models  have  gained  increasing  acceptance  as 
tools  for  computer  system  performance  evaluation  and  prediction.  However,  a 
common  problem  in  using  these  models  is  the  need  to  perform  approximations 
because  the  exact  solution  of  the  model  developed  cannot  be  obtained  with  rea¬ 
sonable  amounts  of  computing  resources. 

Efficient  exact  solution  techniques  are  available  for  a  large,  useful  class  of 
queueing  networks  (those  whose  solution  has  what  is  called  product  form*).  Un¬ 
fortunately,  these  solution  techniques  are  rather  complex,  because  it  is  not  easy 
to  understand  in  an  intuitive  way  why  they  work,  even  though  the  mathematical 
proofs  of  correctness  are  fairly  straightforward. 

In  this  paper  we  present  some  previously  known  solution  techniques  in  a 
framework  that  makes  them  easy  to  understand.  This  framework  allows  us  to 
formulate  a  simpler  (although  less  efficient)  solution  technique  for  a  class  of 
networks  with  a  previously  known  solution  technique  (the  class  change  net¬ 
works),  and  to  present  a  solution  technique  for  a  class  of  networks  for  which  no 
efficient  solution  technique  had  been  previously  published  (those  networks  con¬ 
sidered  in  Lam[77]). 

In  section  II  we  present  background  material.  Section  III  is  a  presentation 
and  explanation  for  the  most  commonly  used  solution  techniques.  Section  IV 
deals  with  the  calculation  of  performance  measures  using  these  techniques. 
Section  V  generalizes  our  view  of  the  solution  algorithms  to  any  conceivable  net¬ 
work  with  a  product  form  solution,  and  deals  more  specifically  with  class  change 
and  Lam-type  networks. 


II.  Product  Form  Networks 

A  queueing  network  is  composed  of  a  set  of  service  centers  with  associated 
transition  paths  between  them,  and  a  customer  population.  A  service  center 
consists  of  a  queue  and  a  server.  The  server  gives  service  to  the  customers  in 
the  queue  at  a  rate  associated  with  the  server.  The  service  discipline  at  a  ser¬ 
vice  center  determines  what  fraction  of  the  total  processing  power  is  assigned  to 
each  station  (position)  in  the  queue.  For  instance,  first-come-first-served  (FCFS) 
scheduling  assigns  a  service  fraction  of  1  to  the  first  station  and  a  service  frac¬ 
tion  of  0  to  the  remaining  stations. 

Customers  in  a  queueing  network  move  from  service  center  to  service 
center  receiving  service.  When  service  is  completed  at  one  center,  the  selection 
of  the  next  center  to  proceed  to  is  based  on  fixed  transition  probabilities.  The 
amount  of  service  required  at  a  server  is  governed  by  a  service  time  distribu¬ 
tion.  If  this  distribution  is  fixed,  the  service  process  is  said  to  be  load  (or  state) 
independent.  If,  however,  the  distribution  depends  on  the  number  of  customers 
in  the  service  center’s  queue,  the  service  process  is  said  to  be  load  dependent. 


*  This  will  be  defined  subsequently. 
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The  set  of  all  customers  is  partitioned  into  subsets,  each  of  which  has  a  set 
of  service  time  distributions  and  transition  probabilities  for  all  the  service 
centers.  Each  of  these  subsets  is  called  a  customer  class.  Members  of  a  single 
customer  class  are  statistically  identical;  that  is,  they  are  not  distinguishable  by 
their  behavior. 

Customers  of  each  class  enter  the  network  from  an  external  source  at 
some  (possibly  0)  rate,  and  leave  the  network  after  completion  of  service  at  a 
center  with  some  (possibly  0)  probability.  If  there  is  some  finite  limit  to  the 
number  of  customers  of  a  class  that  may  be  in  the  network  at  one  time,  the 
class  is  closed;  otherwise,  it  is  open.  A  network  with  only  open  classes  is  called 
open;  a  network  with  only  closed  classes  is  called  closed;  one  with  both  types  of 
classes  is  mixed. 

By  the  solution  of  a  queueing  network,  we  generally  mean  the  determina¬ 
tion  of  the  equilibrium  probabilities  for  the  states  of  the  network.  A  state  of  the 
network  is  described  by  all  the  information  necessary  to  determine  the  rate  at 
which  each  of  the  customers  in  the  network  can  be  expected  to  change  position 
(either  by  moving  within  a  service  center  or  by  moving  from  one  center  to 
another).  For  the  types  of  networks  considered  in  this  paper,  a  sufficient 
representation  of  a  state  is  a  listing  of  the  class  of  the  customer  in  each  station 
of  the  queues  of  all  the  service  centers. 

A  closed  network  with  M  service  centers  is  said  to  have  a  product  form 
solution  if  the  equilibrium  state  probability  of  any  state  5  is  given  by  a  function 

p(s)  =  n  a  (v<) 

U-  i  =  l 

Here,  yi  is  the  customer  population  at  center  i,  fi(yi)  is  a  function  that  depends 
on  the  service  discipline  and  service  time  distribution  at  center  i,  and  is  a 
normalizing  constant  that  causes  the  sum  of  the  state  probabilities  to  be  one. 

The  principle  problem  in  solving  product  form  networks  is  that  the  number 
of  states  grows  exponentially  with  the  number  of  customers  and  service  centers. 
This  means  that  it  may  be  infeasible  to  evaluate  G  by  a  direct  summation,  both 
because  the  computation  would  be  too  expensive  and  because  it  would  be 
numerically  unstable.  Instead,  a  number  of  efficient  computational  algorithms 
have  been  developed  to  obtain  the  normalizing  constant  G.  These  algorithms 
also  yield  simple,  numerically  stable  expressions  for  performance  measures 
commonly  of  interest  (e.g.,  server  utilization). 


HI.  Computational  Techniques 

Consider  closed  queueing  networks  consisting  of  FCFS  exponential  service 
centers  with  load  independent  exponential  service  times  and  a  single  customer 
class  of  N  customers.  Let  be  the  static  probability  of  a  customer  proceeding 
directly  to  a  center  j  after  completing  service  at  center  i.  Then  the  real,  posi¬ 
tive  valued  Vj.j—  satisfying 

u 

Vi  =  £  Pa  *Vi 

i=l 

are  called  the  relative  throughputs  of  the  network.  We  define  X f  -  y^/u^,  where 
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11+  is  the  service  rate  of  center  i.  Each  Xi  is  interpreted  as  the  relative  utiliza¬ 
tion  of  center  i;  that  is,  the  ratio  of  Xi  to  Xj  is  the  same  for  all  i  and  j  as  the 
ratio  of  the  absolute  utilizations  of  centers  i  and  j  in  the  network. 


The  solution  to  the  networks  described  above  (Jackson[63],  Gordon  & 
Newell[68])  is  given  by 


P(S)  = 


_1 _ 

Cjf(AT) 


u 

rur* 


where  5  is  a  valid  state,  n*  is  the  number  of  customers  at  center  i,  Xi  is  the  rela¬ 
tive  utilization  of  service  center  i,  and 


( 


C„(N) 


i-sn^ 


t=i 


(where  the  summation  is  taken  over  all  feasible  states)  is  the  normalizing  con¬ 
stant.  Our  problem  is  to  compute  Gy(N)  efficiently. 


The  following  scheme  (Buzen[73])  efficiently  sums  the  state  probabilities: 

Gi(n)  =  Gi-i(n)  +  JK<*C<(n-l),  i  =  1.  2 . M:  n  =  0. 1 . N  (1) 

with  the  initial  condition  that  Gi(0)  =  1,  and  the  assumption  that  Gq(tl)  =  0  for 
all  n.  The  normalizing  constant,  G(N),  is  then  computed  as  Gj#(AT). 


This  technique  can  be  visualized  (and  implemented)  as  shown  in  figure  1. 
It  is  easy  to  verify  mathematically  that  the  computation  is  correct,  but  it  is  a  lit¬ 
tle  more  difficult  to  see  just  what  is  actually  happening. 


Consider  Gi(n).  Its  value  is  Jf?.  This  represents  the  term  in  the  state 
probability  for  any  state  having  n  customers  at  center  1.  Now  consider  C2(n+1). 
This  is  the  sum  of  the  factors  of  the  state  probabilities  corresponding  to  having 
n+1  customers  at  the  first  two  service  centers.  From  (1)  we  see  that 

Gq{ti  + 1)  =  G  i(ti  +  l)  +  X%*G 2(71 )  =  G  1(71  +  l)  +  Xz*  (G  i(n )  +  X%*G 2(71  —  1)) 

The  first  term,  C1(7i  +  l),  is  the  relative  probability  of  having  all  71  + 1  customers 
at  center  1.  The  X^G^iji)  term  is  the  relative  probability  of  having  71  customers 
at  center  1  and  one  at  center  2.  If  we  further  expand  the  last  term, 
Xz*XfGz{n-l)  by  expanding  the  Gz{ti—  l)  factor  in  a  manner  similar  to  that  for 
G 2(71),  we  will  find  that  Gz{ri+i)  is  the  sum  of  the  relative  probabilities 
representing  all  the  ways  of  placing  71 +  1  customers  at  the  first  two  servers. 

In  general,  an  element  Gi(n)  represents  the  factor  in  the  relative  probabil¬ 
ity  that  n  customers  are  resident  in  the  first  i  service  centers  in  any  of  the  pos¬ 
sible  allocations  of  customers  to  service  centers.  This  is  computed  (according 
to  equation  (l))  by  accounting  for  the  possibility  of  adding  the  71**  customer  to 
service  center  i  (the  Xi*Gi(n-l)  term)  and  the  possibility  that  all  n  customers 
are  at  the  previous  i- 1  centers  (hence,  the  +  Gi-i(rt)  term).  Since  Gy(N)  is  the 
sum  of  the  relative  probabilities  of  all  the  ways  to  distribute  the  N  customers 
among  the  M  service  centers  (i.e.,  all  the  states),  it  is  the  normalizing  constant. 


Another  way  of  looking  at  this  is  to  consider  the  set  of  all  possible  paths 
consisting  only  of  downward  (7i-m  +  l)  and  rightward  (i-»i  +  l)  links  from  Ci(0)  to 
Gy(N).  Each  such  path  represents  a  feasible  state  of  the  system.  The  number 
of  downward  links  for  each  column  i  is  the  number  of  customers  at  service 
center  1  It  is  easy  to  show  that  there  is  exactly  one  such  path  for  each  feasible 
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state.  Since  downward  links  in  column  i  result  in  a  multiplication  by  Xi  in  the 
computational  algorithm,  and^each  rightward  link  leaves  the  entry  unchanged, 

the  computation  computes  X^,  where  n  is  the  number  of  downward  links 

i=  1 

(customers)  at  column  (center)  i.  The  Buzen  algorithm  computes  all  such  paths 
in  an  efficient  manner  by  computing  an  initial  segment  (i.e.,  the  allocation  of  n 
customers  to  the  first  i  service  centers)  only  once  and  using  it  to  compute  all 
paths  that  can  be  formed  from  the  initial  segment  (i.e.,  all  ways  to  allocate  the 
remaining  N—n  customers  to  the  remaining  M—i  centers). 

We  now  consider  networks  with  one  or  more  load  dependent  service 
centers.  Let  center  i  be  load  dependent.  Let  the  service  rates  at  center  i  be  w* 
when  there  is  one  customer  in  its  queue,  and  when  there  are  k  custo¬ 

mers  present.  The  state  probabilities  are  given  by 

^(S)  =  7rn!4V  ft  0,0)1 

^  i- 1  j =0 

where  ao  is  defined  to  be  1. 

Buzen[73]  gives  an  efficient  algorithm  for  determining  the  normalizing 
constant  for  load  dependent  exponential  networks.  Again,  the  term  G<(to)  is  the 
sum  of  all  factors  of  the  state  probabilities  of  states  having  n  customers  at  the 
first  i  centers.  This  algorithm  is  more  complicated  than  the  previous  one 
because  the  rate  at  which  a  service  center  serves  is  dependent  on  the  total 
number  of  customers  at  that  center.  We  therefore  cannot  use  the  same  compu¬ 
tation  for  the  initial  vector  of  two  customers  at  center  1  and  one  at  center  2  to 
compute  the  relative  probability  mass  for  two  customers  at  center  1  and  two  at 
center  2.  Instead,  a  vector  convolution  is  used  to  compute  the  required  terms 
separately  for  all  possible  numbers  of  customers  at  center  i  in  order  to  get 
Gi(n).  This  operation  is  shown  in  figure  2.  The  algorithm  multiplies  the  correct 

factor,  Hi(j )  =  X(/f\  a. £(fc),  by  the  relative  probability  of  Gi-\(n-j)  separately 

k  =  l 

for  each  n.  These  products  are  summed  for  all  j—0,  1  and  therefore  taken 

into  account  all  the  different  numbers  of  customers  that  may  actually  be  at 
center  i. 

As  the  extra  work  of  performing  the  convolution  required  for  load  depen¬ 
dent  service  centers  is  necessary  only  for  the  C£  corresponding  to  load  depen¬ 
dent  centers  i,  the  Gj  corresponding  to  load  independent  centers  j  can  be  com¬ 
puted  by  the  more  efficient  load  independent  method.  This  mixture  of  the  two 
algorithms  can  lead  to  significant  performance  improvement  in  the  computation 
of  the  normalizing  constant  for  a  system  with  many  load  independent  service 
centers  and  few  load  dependent  ones. 

The  class  of  product  form  networks  was  expanded  over  those  considered  in 
Buzen[73]  by  Baskett  et  al.[75].  They  showed  that  networks  with  multiple 
classes  of  customers  and  with  service  centers  following  certain  restrictions  as  to 
service  discipline  and  service  time  distribution  have  product  form  solutions. 

Reiser  and  Kobayashi[75],  Chandy  et  al.[76],  and  others  have  given 
efficient  computational  algorithms  to  compute  the  normalizing  constant  for 
these  more  general  networks.  These  algorithms  are  generally  referred  to  as 
convolution  algorithms,  although,  as  pointed  out  in  Reiser  and  Kobayashi[75], 
the  convolution  operation  is  necessary  only  in  the  cases  of  networks  with  load 
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dependent  service  centers.  With  Baskett  et  al.-type  networks  also,  it  is  possible 
to  combine  the  load  dependent  and  load  independent  algorithms  to  save  compu¬ 
tation. 

We  present  here  an  explanation  for  the  load  independent  algorithm.  The 
way  in  which  the  load  dependent,  or  convolution,  algorithm  differs  will  be 
explained  subsequently. 

Consider  a  set  of  J/i?-dimensional  matrices  Gi,i  =  l,  where  the  size  of 

Ct  in  the  rth  dimension  is  Nr+ 1  (Gt  is  indexed  0:^r).  These  matrices  can  be  used 
to  compute  the  normalizing  constant  for  networks  with  R  classes  of  customers, 
with  Nr  being  the  number  of  customers  in  class  r,  r  =  1,  2,...,/?.  The  interpreta¬ 
tion  of  any  element  G^n^ng,  .  .  .  ,nR)  is  that  it  is  the  part  of  the  product  form 
solution  corresponding  to  n i  customers  of  class  1,  n2  customers  of  class  2,...,7ifl 
customers  of  class  R  being  at  the  first  i  service  centers.  To  calculate  the  nor¬ 
malizing  constant  for  these  networks  we  need  to  calculate  Glf  then  Gg,...,  and 
finally  G a,  where  these  matrices  are  similar  to  those  used  in  the  Buzen  algo¬ 
rithm.  The  normalizing  constant  is  then  given  by  a  term  of  G^, 

The  calculation  of  the  normalizing  constant  in  the  multi-class  case 
proceeds  in  the  same  manner  as  does  the  Buzen  algorithm.  The  only  additional 
complication  is  that  we  must  use  multi-dimensional  matrices  for  the  Gi  to  hold 
information  about  the  number  of  customers  of  each  class  at  center  i.  The  gen¬ 
eral  algorithm  then  is  described  by 

R 

Giin^riR,  .  .  .  ,nR)  =  (nlt  .  .  .  ,  nR)  +  £  Xir  *  Gt(«t . nr-l,...tnR)(2) 

r=l 

where  X^r,  the  relative  utilization  of  service  center  i  by  class  r  customers,  is 
computed  class  by  class  in  a  manner  identical  to  that  for  single  class  networks. 
Note  the  similarity  to  (1),  the  Buzen  algorithm. 

To  illustrate  how  the  algorithm  works  in  the  multi-class  case,  we  present 
an  example  of  a  system  with  N  customers  of  class  1  and  N  customers  of  class  2. 
The  initial  G  j  is  shown  in  figure  3.  At  this  point,  the  only  known  value  is  6^(0,  0), 
which  is  one,  so  we  can  construct  only  Gi(l,  0)  and  Gi(0,  1).  This  is  shown  in 
figure  4.  We  can  now  construct  Gi(l,  1)  using  our  recursive  formula  (2)  (figure 
5).  Gi(l,  l)  is  constructed  by  introducing  one  customer  of  class  2  to  G^l.O) 
(that  is,  multiplying  by  AT 1,2),  and  one  of  class  1  to  Gi(0,  1)  (multiplying  by  A^.i). 
Note  that  these  two  paths  from  Gi(0,  0)  to  Gi(l,  l)  represent  all  possible  order¬ 
ings  of  one  class  1  and  one  class  2  customer  at  center  1.  Note  also  that  the  fac¬ 
tor  computed  for  each  path  is  the  same  (i.e.  Xltl  *Xl  z).  In  general,  the  term 

G  1(71^71%)  will  be  the  sum  of  (ni+712)  !  /  (tzi!)  (rig-)  terms  of  Afi,1!  *  X\  %,  each  one 
of  which  represents  a  distinct  path  from  G^O,  0)  to  C1(ni,n2).  G1(nI,n2)  is 
therefore  exactly  the  term  in  the  relative  marginal  probability  for  (ni,n2)  custo¬ 
mers  at  center  1. 

Now  consider  G2.  An  element  G2(7ii,n2)  is  the  term  in  the  relative  marginal 
probability  that  n\  customers  of  class  1  and  n2  of  class  2  are  resident  at  either 
center  1  or  2.  C2(l,  0)  therefore  is  X^i  *GS(0,  0)  +  &!(!,  0).  Similarly,  G2(2,  0)  is 
X2,  1  *G2(1,  0)  +Ci(2,  0).  This  can  be  expanded  to  Xz,  1  *{Xz,  1  +  Ci(l,  0))  +  Ci(2,  0). 
It  therefore  rpresents  all  possible  allocations  of  two  class  1  customers  to  the 
first  two  service  centers.  In  general, 

Gi(n i,n2)  =  Xi'i  *Gi(7i1“l,7t2)  +  Xi2  *G(n1,n2- 1)  +  G^^n^ng) 
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The  first  two  terms  represent  adding  a  customer  of  the  appropriate  class  to 
those  terms  lacking  exactly  one  customer  of  that  class,  and  the  last  term  takes 
into  account  the  possibility  that  all  (711,712)  customers  were  allocated  to  the  pre¬ 
vious  i—  1  centers. 

By  repeating  this  process  M  times  ( M  is  the  number  of  service  centers),  we 
will  have  looked  at  all  possible  paths  from  £i(0,  0)  to  JV2).  Since  each  path 

corresponds  to  a  state,  we  will  have  summed  the  relative  probabilities  over  all 
possible  states.  CM(N itN g)  is  therefore  the  normalizing  constant. 

For  networks  with  load  dependent  service  centers,  the  algorithm  is  slightly 
different.  In  these  cases,  the  rate  of  a  service  center  depends  on  the  number  of 
customers  at  that  service  center.  Therefore,  we  cannot  simply  multiply 
GiCni-l.ng)  by  Xi  1  to  get  a  term  for  £1(71,1,712).  since  the  correct  multiplicative 
factor  depends  on  whether  the  added  customer  represents  the  first,  second, 
third,  up  to  7ii+ls*  class  1  customer  at  center  i*.  Instead,  G^n^, nz)  is  the  sum 

E  E  *  Hiij.k) 

j  =0  jfc=0 

where  Hi(J,k)  represents  the  load  dependent  factor  for  j  customers  of  class  1 
and  k  customers  of  class  2  at  center  i.  The  term  Hi(jjk)  represents  the  factor  in 
the  state  probabilities  corresponding  to  j  customers  of  class  1  and  k  of  class  2  at 
center  x.  For  the  load  independent  case  this  is  (J  +k)\/(j\k\)  *  X(i  *  X*z  (recall 
the  discussion  of  G\{j,k)  for  an  explanation).  The  computation  given  above  is 
simply  the  matrix  convolution  of  £*_i  with  H *.  Each  term  of  the  summation 
represents  the  relative  probability  that  there  are  j  customers  of  class  1  and  k  of 
class  2  at  center  i,  and  txi-j  of  class  1  and  712-k  of  class  2  distributed  among  the 
first  x  — 1  service  centers. 

Notice  that,  like  the  Buzen  algorithm,  this  algorithm  constructs  all  possi¬ 
ble  paths  from  C  1(0,0)  to  Gjf(Ni,Nz),  and  that  each  element  £*(711,712) 
represents  the  relative  probability  that  (711,712)  customers  are  distributed 
among  the  first  i  service  centers.  The  convolution  is  required  only  because  the 
terms  comprising  the  relative  probability  £i(7Xll7i2)  must  be  multiplied  by 
different  factors  to  get  £*(7x1,712)  depending  on  how  many  of  the  n  class  1  custo¬ 
mers  are  actually  at  service  center  x.  However,  the  basic  method  of  the  algo¬ 
rithm  is  unchanged. 


IV.  Performance  Measures 

Once  one  has  obtained  the  normalizing  constant  £  for  a  given  network, 
various  performance  measures  can  be  calculated  by  summing  the  probabilities 
of  the  appropriate  states.  For  example,  using  our  two  class  network  with  FCFS 
scheduling  as  an  example,  the  utilization  of  service  center  i  by  class  1  is  the  sum 
of  the  probabilities  of  all  states  having  a  class  1  customer  at  the  head  of  center 
x's  queue.  Depending  on  the  size  of  the  network,  this  summation  could  be  very 
expensive. 


*  Recall  that  £*(7x1,712)  represents  the  sum  of  the  relative  probabilities  of  all 
states  with  (7Xi,7i2)  customers  at  the  first  x  service  centers.  Center  i  therefore 
may  have  0,  l,...,7ii  customers  of  class  1  at  it  when  we  add  the  7ii+lsJ  customer 
of  class  1. 
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It  is  possible  to  compute  efficiently  a  number  of  performance  measures  of 
interest  by  using  the  summations  already  performed  in  computing  the  normaliz¬ 
ing  constant  G  (Buzen[73]).  For  simplicity,  we  restrict  our  examples  here  to 
load  independent  networks.  However,  similar  results  for  load  dependent  net¬ 
works  are  obtainable  by  appropriate  modifications. 

Utilization  -  The  utilization  of  center  i  by  class  r  customers  is  the  sum  of  the 
probabilities  of  all  states  having  a  class  r  customer  at  service  center  i,  and  all 
other  customer  distributed  in  any  way  among  the  other  centers.  For  load 
independent  centers  i,  this  number  is 

.  l . Afr-l . 

ir  CU(N1 . Nr) 

The  Gh(N \,N 2,. ,.,Nr—  1,...,NR)  term  represents  the  sum  of  the  relative  probabili¬ 
ties  of  having  ( )  customers  distributed  in  any  manner  among 
the  M  service  centers,  and  the  X^r  ensures  that  there  is  a  class  r  customer  at 
(the  head  of  the  queue  of)  service  center  i.  The  Gu(Nx,...,NR)  term  is  the  nor¬ 
malizing  constant  to  turn  the  relative  probabilities  into  absolute  probabilities. 

Queue  Lengths  -  The  queue  length  distribution,  and  therefore  the  mean,  for  each 
class  at  a  service  can  be  computed  in  a  similar  fashion.  The  probability  that  j 
customers  of  class  r  are  in  center  M's  queue  is  given  by*: 

1  (Nt,....Nr_1.j.Nr . Nr) 

Pm. rO)  =  77  *  E  Hu(nx,  .  .  .  ,  nR)  •  GM-t(N l-ni,...,NR-nR) 

u  ne(0 . j . 0) 

and  the  mean  queue  length  is  given  by 

*T 

Qm.t  -  E  j  *  Pu.r 

3  =  1 

A  simpler  expression  for  is  possible  for  centers  i  which  are  load  independent 
for  class  r.  For  these  centers 

=  Xi.r  *  Cm+1(JV, Nr- 1, Nr) 

where  Gy+X  is  obtained  by  applying  the  appropriate  load  dependent  or  indepen¬ 
dent  algorithm  to  Gu  using  the  relative  utilizations  of  center  i.  This  result  can 
be  obtained  by  algebraic  manipulation  of  the  load  dependent  formula. 

The  other  commonly  sought  performance  measures,  such  as  mean 
throughput  and  response  time,  can  then  be  obtained  from  utlization  and  queue 
length  statistics  using  well-known  equations. 


*  Statistics  for  an  arbitrary  center  can  be  computed  by  renumbering  so  that  the 
desired  center  is  the  Mih  in  the  computation. 
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V.  Other  Networks 

The  networks  considered  by  Baskett  et  al.[75]  permit  the  probabilistic 
change  of  class  membership  by  a  customer  when  it  travels  from  one  service 
center  to  another.  The  set  of  all  classes  such  that  a  customer  in  one  of  the 
classes  can  become  a  customer  in  each  of  the  other  classes  through  one  or 
more  class  changes  is  called  a  closed  chain. 

A  number  of  people  have  dealt  with  the  problem  of  obtaining  the  normaliz¬ 
ing  constant  for  class  change  networks  (Reiser  and  Kobayashi[75],  Wong[75], 
Balbo  et  al.[77],  Bruell[78].  However,  all  these  methods  perform  complicated 
computations  to  deal  with  the  class  change  problem. 

A  simple  (although  less  efficient)  computational  method  is  possible  which 
is  a  simple  extension  of  the  basic  convolution  algorithm.  Consider  a  network 
with  two  customer  classes.  Let  class  1  and  class  2  be  in  the  same  closed  chain, 
chain  A,  and  let  there  be  NA  customers  in  that  chain.  Assume  also,  for  simpli¬ 
city,  that  all  service  centers  are  load  independent. 

This  network  can  be  solved  by  the  simple  multi-class  load-independent 
algorithm  previously  proposed,  but  with  some  minor  alterations  in  the  states  for 
which  the  relative  probability  masses  are  computed.  In  the  load  independent 
algorithm  we  needed  to  construct  every  path  from  (0,  0)  to  (N \,Nz),  and  so  rec¬ 
tangular  matrices  were  used  for  the  C4.  For  the  class  change  network,  we  need 
to  construct  every  path  from  (0,  0)  to  (N 0),  1),  .  .  .  ,  (0,AT2)  (i.e.,  from 

(0,  0)  to  every  possible  customer  population).  This  induces  the  triangular  matrix 
for  Gi  shown  in  figure  6.  The  computation  done  to  produce  each  element  (i,J )  is 
exactly  the  same  as  that  of  equation  (5);  however,  we  restrict  ourselves  to  those 
elements  (i,j)  that  correspond  to  feasible  numbers  of  class  1  and  class  2  custo¬ 
mers  resident  at  center  k  (i.e.,  all  states  for  which  i+j  £  NA). 

Once  we  have  performed  the  algorithm  to  compute  Ci.Gg,  ....  Gy,  the  nor¬ 
malizing  constant  G  is  given  by 

c  =  1/  E 

3=0 

This  represents  the  inverse  of  the  total  probability  mass  of  all  feasible  states, 
where  feasible  means  that  all  NA  customers  in  chain  A  are  distributed  between 
the  two  classes  in  that  chain. 

To  get  class  dependent  performance  measures,  we  compute  expressions 
similar  to  those  given  in  section  IV.  In  general,  wherever  the  term 

GuW  i-j.N2)/GM(Ni,Nz) 
had  appeared  before,  we  now  substitute 

,  na~3 

(77)*  E  GuWA-k-j,k) 

u  h=0 


For  example,  the  utilization  of  service  center  i  by  class  1  in  our  simple 
class  network  is  given  by 

7^u*sWi-U) 

^  *=0 
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The  j  term  represents  the  fact  that  one  class  1  customer  is  at  service  center 
i,  and  the  summation  represents  all  the  ways  that  the  other  customers  in  all  the 
possible  allocations  of  the  AT*  customers  between  the  two  classes  may  be  allo¬ 
cated  to  the  M  service  centers. 

The  idea  of  using  the  basic  algorithm  to  compute  the  normalizing  constant 
is  valid  for  any  network  with  a  product  form  solution.  One  simply  applies  the 
algorithm  to  construct  all  paths  from  (0,  0,...,  0)  to  (Af  i.^ATgi.  .  •  .  ,Nra),  where 
each  vector  {N\  i,Nz,i,  .  .  .  . N r^)  represents  a  feasible  customer  population  of 
the  network.  The  normalizing  constant  G  then  is 

0  =  1/E  ^(A^AT*, . AT**) 

i 

for  eill  i  s.t.  (Ntj.NZ'i,  .  .  .  .Nrj)  is  valid  and  the  load  Independent  performance 
measurements  are  given  by  the  following: 

Utilization  of  service  center  k  by  class  r\ 

. \  :  ,-j  '.v :  , 

•  •  '  *  . *  .  r 

C4.r  =  (h  *  XKr  •  £Cv(tf, .,.//*< . . Nm)  (3) 

G  i 

Probability  of  j  customers  of  class  r  at  center  M: 

1  Wi . *-•■**) 

Pm.t(J)  =  (7 7)  *  E  HmW  *  Gm-i(N rnj,  .  .  .  .Nr-ur)  (4) 

Mean  queue  length  of  class  r  customers  at  center  M: 

Q*r=  E  J  *  Pu.rU)  (5) 

i=i 

A  simplification  for  QytT  analogous  to  that  given  for  multiple  class  networks  is 
possible  for  service  centers  that  are  load  independent  with  respect  to  class  r 
customers. 

As  a  further  example,  we  can  apply  our  general  algorithm  to  Lam-type  net¬ 
works  (Lam[77]).  Lam  showed  that  networks  meeting  Baskett  et  al.[75]  restric¬ 
tions  but  with  certain  classes  of  load  dependent  arrivals  and  departures  are  in 
product  form.  These  network  allow  for  the  number  of  customers  in  each  closed 
chain,  as  well  as  in  each  class,  to  vary.  Therefore,  the  total  number  of  custo¬ 
mers  in  a  "closed"  network  may  vary. 

To  compute  the  normalizing  constant  for  these  networks,  one  computes 
G\,G%,  ....  Gjj,  where  each  G*  is  of  sufficient  size  in  each  dimension  r  to  allow  for 
the  maximum  number  of  customers  of  class  r  possible  in  the  system.  Again,  one 
is  constructing  all  paths  from  (0,  0,...,  0)  to  all  (A f  i.i.A/^,  ■  ■  .  .AT#*),  that  is,  allo¬ 
cating  all  customers  in  each  possible  customer  population  among  the  service 
centers  in  all  possible  ways.  The  performance  measures  for  these  networks  can 
then  be  computed  using  equations  3-5. 
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Summary 

We  have  shown  that  the  seemingly  complicated  convolution  algorithms  for 
queueing  network  solutions  are  really  simple  extensions  of  Buzen’s  original  algo¬ 
rithm  [Buzen  73].  This  was  done  by  providing  a  simple  intuitive  viewpoint  that 
applies  to  all  the  algorithms.  This  vewpoint  suggests  a  single  computational 
algorithm  that  applies  to  all  closed,  separable  networks.  An  application  of  this  is 
a  solution  technique  for  Lam-type  networks  [Lam  77],  a  class  of  networks  for 
which  no  solution  algorithm  had  been  previously  published. 
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Operational  Analysis  Versus  Stochastic  Modelling 

of  Computer  Systems 
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University  of  Toronto 


Abstract 

The  emergence  of  "operational  analysis"  as  an  approach  to  analytic  com¬ 
puter  system  performance  evaluation  has  led  to  an  extensive  discussion  of  its 
merits  relative  to  the  established  approach  of  modelling  computer  systems  with 
stochastic  processes.  After  briefly  summarizing  and  contrasting  the  two  ap¬ 
proaches,  we  present  some  examples  that  clarify  certain  differences  between 
the  two  approaches.  We  discuss  the  arguments  that  have  been  put  forth  both  for 
and  against  operational  analysis,  adding  our  own  opinion.  We  conclude  that 
operational  analysis  is  conceptually  simpler  and  more  directly  applicable  to  ac¬ 
tual  computer  systems  than  stochastic  analysis.  Further  developments  in 
operational  analysis,  however,  are  needed  to  supplant  use  of  some  stochastic 
analysis  results. 


This  paper  will  appear  in  the  Proceedings  of  Computer  Science  and  Statistics: 
12th  Annual  Symposium  on  the  Interface,  University  of  Waterloo,  May  1979. 
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L  Introduction 

After  several  years  of  discussion,  opinions  on  the  role  and  contribution  of 
operational  analysis  remain  divided.  At  one  extreme,  operational  analysis  is 
touted  as  a  new  mathematical  framework  that  eliminates  the  need  for  stochas¬ 
tic  models  in  computer  system  performance  evaluation.  At  the  other  extreme, 
operational  analysis  is  said  to  contribute  nothing  new  beyond  intuitive  relation¬ 
ships  that  are  ineffective  in  supporting  the  task  of  predicting  a  computer 
system's  performance  under  altered  circumstances.  On  both  sides,  there  have 
been  emotional  overtones  to  the  technical  arguments. 

We  attempt,  in  this  paper,  to  examine  the  arguments  on  each  side,  to 
present  some  new  evidence  in  the  form  of  some  examples,  and  to  summarize  our 
view  of  the  relative  advantages  of  operational  analysis  and  the  more  established 
probabilistic  approach,  which  we  will  refer  to  as  stochastic  analysis.  We  will  res¬ 
trict  our  discussion  to  closed  queueing  networks  in  which  customers  are  indis¬ 
tinguishable.  In  sections  two  and  three,  we  describe  stochastic  analysis  and 
operational  analysis  respectively,  emphasizing  those  aspects  that  will  be  impor¬ 
tant  to  our  comparison.  In  section  four,  we  present  three  examples  that  clarify 
certain  differences  between  the  two  approaches.  In  section  five,  we  discuss  in 
detail  certain  strengths  and  weaknesses  of  the  two  approaches,  and  we  suggest 
areas  in  which  further  development  of  operational  analysis  would  be  beneficial. 


II.  Stochastic  Analysis 

A  queueing  network  model  consists  of  service  centers  among  which  custo¬ 
mers  circulate.  At  each  visit  to  a  service  center,  a  customer  receives  service, 
the  duration  of  which  is  taken  to  be  a  sample  from  a  specified  distribution. 
From  each  center,  a  probability  distribution  governs  the  frequency  with  which  a 
customer  moves  to  each  other  service  center. 

By  making  several  assumptions,  the  queueing  network  model  can  be 
viewed  as  a  stochastic  process.  The  assumptions  are  the  following: 

(1)  successive  service  times  are  independent, 

(2)  successive  transitions  among  service  centers  are  independent. 

If  the  service  time  distribution  at  each  center  is  exponential,  then  the  sys¬ 
tem  state  (which  is  defined  as  the  number  of  customers  at  each  service  center, 
n  =  (7i|,n2,..„nm))  is  a  continuous-time  Markov  process.  If,  additionally, 

(3)  the  process  is  ergodic,  and 

(4)  the  system  reaches  equilibrium, 

then  the  steady-state  probability  distribution  of  system  state  is  given  by: 

p(")  =  -^n(s(Vi)"<  (i) 

u  i  =  l 


where  S’*  is  the  average  service  time  at  center  i,  Xi  is  the  relative  number  of 
visits  to  center  i,  and  G  is  a  normalization  constant  which  forces  the  sum  of  pro¬ 
babilities  over  all  states  to  add  to  one. 
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If  the  mean  of  the  exponential  distribution  from  which  service  times  are 
drawn  is  dependent  on  the  number  of  customers  currently  at  the  center,  the 
state  probability  equation  generalizes  to 

peo^no^iiw)  (2) 

^  t=l  k =1 

where  Si(k)  is  the  mean  service  time  at  center  i  with  k  customers  there. 

From  the  probability  distribution  of  system  state,  it  is  possible  to  derive 
expressions  for  such  performance  measures  as  utilizations,  queue  length  distri¬ 
butions,  and  mean  response  time  [3]. 

The  parameters  of  the  stochastic  process  representing  the  operation  of 
the  system  must  be  estimated  from  observations  during  a  finite  time  interval. 
The  specific  formulae  depend  on  what  measurement  data  is  available  and  on  the 
amount  of  detail  in  the  queueing  network  model.  The  three  formulae  below, 
however,  give  the  flavour  of  the  calculations. 

Xi  =  Oi/Ci 


Si  =  Bi/Oi 


N  =  (£  Ts)/Ct 

i 

where  all  the  variables  pertain  to  a  particular  observation  period  and  are 
defined  as  follows: 

Oi  =  number  of  operations  at  device  i 

Bi  -  time  device  i  was  busy 

Ci  =  number  of  jobs  completed 

Tj  =  time  in  system  of  jth  job 

Vi  =  mean  number  of  visits  to  device  i  per  job 

Si  =  mean  service  time  at  device  i 

N  =  multiprogramming  level 

These  are  estimates  of  the  parameters  of  the  postulated  underlying  stochastic 
process  based  on  the  particular  observation  period. 

In  order  to  validate  the  model,  the  estimated  parameter  values  are 
plugged  into  the  performance  measure  formulae,  and  the  results  are  compared 
to  the  corresponding  observed  values  in  the  observation  period.  Agreement  is 
typically  not  exact,  but  a  stochastic  process  does  not  have  identical  behaviour  in 
all  finite  time  periods  of  equal  length,  so  imprecise  agreement  does  not  invali¬ 
date  either  the  assumption  of  an  underlying  stochastic  process  or  the  particular 
means  of  parameter  estimation. 

The  most  common  purpose  for  which  models  are  created  is  to  obtain  an 
indication  of  how  a  system  will  behave  in  the  future  after  either  its  configuration 
has  been  altered  or  its  workload  has  changed.  In  order  to  accomplish  this,  it  is 
possible  to  use  the  same  computational  formulae  as  in  the  validation  of  the 
model,  but  using  modified  parameter  values  in  order  to  reflect  the  altered 


-20- 


l 


circumstances  anticipated  in  the  future.  Some  such  changes  are  easily 
reflected  in  models  while  others  are  not.  For  example,  replacing  the  cpu  with 
one  that  is  twice  as  fast  would  be  reflected  by  halving  the  mean  cpu  service 
time.  Adding  an  additional  channel  and  balancing  the  load  across  channels  can 
be  represented  by  adding  a  new  service  center  with  the  same  service  charac¬ 
teristics  as  the  other  channels  and  altering  the  visit  counts  to  approximately 
equalize  the  load  at  the  channels.  Adding  more  memory  is  typically  represented 
only  implicitly  by  increasing  the  multiprogramming  level  or  by  reducing  the 
relative  frequency  of  visits  to  a  paging  device  to  indicate  a  lower  degree  of  con¬ 
tention  for  memory  space  among  active  jobs.  Parameters  not  directly  affected 
by  the  modifications  to  the  system  are  assumed  to  be  invariant. 

Once  the  future  values  of  the  model  parameters  have  been  estimated,  the 
formulae  given  earlier  are  used  to  calculate  the  performance  measures.  These 
are  then  interpreted  as  equilibrium  performance  measures  of  a  stochastic  pro¬ 
cess.  It  cannot  be  proven,  nor,  in  general,  disproven  that  a  given  finite 
behaviour  sequence  is  governed  by  a  specified  stochastic  process.  Validation  of 
the  model  after  observing  the  modified  system  involves  validating  not  only  the 
predicted  performance  measures  but  also  the  parameter  estimations. 

In  summary,  stochastic  analysis  postulates  an  underlying  stochastic  pro¬ 
cess  that  governs  the  behaviour  sequences  of  the  computer  system  in  finite 
observation  periods.  By  estimating  future  parameters  values,  another  stochas¬ 
tic  process  is  determined  and  its  equilibrium  performance  measures  can  be  cal¬ 
culated.  It  is  then  presumed  that  observation  periods  of  the  modified  system 
will  be  behaviour  sequences  governed  by  the  stochastic  process.  Thus,  in  any 
single  future  observation  interval,  observed  performance  values  are  unlikely  to 
coincide  perfectly  with  the  equilibrium  performance  values  of  the  stochastic 
process.  Over  a  large  number  of  such  future  observation  intervals,  however,  it  is 
expected  that  the  cummulative  performance  measures  would  tend  to 
correspond  closely  to  those  of  the  stochastic  process. 


III.  Operational  Analysis 

Operational  analysis  is  based  on  measurable  values,  testable  assumptions, 
and  finite  observation  periods.  The  basic  model  parameters  are  counts  in  a 
finite  observation  interval  of  arrivals  to  centers,  completions  at  centers  and 
transitions  between  pairs  of  service  centers.  The  basic  operational  quantities 
are: 


Ci(k )  =  number  of  service  completions  at 
center  i  with  k  customers  there 

A{  —  number  of  arrivals  to  center  i 

7 \(fc)  =  time  during  the  interval  for  which  there 
were  exactly  k  customers  at  center  i 

C0  =  number  of  customers  whose  service  is 
completed. 


Then,  the  following  quantities  are  derived: 
Si(k)  =  Ti(k)/Ci(k) 
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Vi=At/C0 

The  parameter  is  the  number  of  visits  to  device  i  percustomer  completion  in 
the  observation  period.  Note  that  this  is  a  different  interpretation  of  relative 
to  stochastic  analysis,  but  it  is  precisely  the  formula  used  to  estimate  the  sto¬ 
chastic  parameter  based  on  the  observation  period.  Similarly,  the  values 
are  interpreted  as  the  service  function  of  center  i  in  operational 
analysis,  while,  in  stochastic  analysis,  they  are  the  inverses  of  the  load- 
dependent  service  rates  at  center  i.  As  will  be  shown  in  examples  later,  the  ser¬ 
vice  functions  do  not  correspond  directly  to  mean  service  times,  since  they  are 
influenced  also  by  patterns  of  customer  movement  among  centers.  Again  the 
stochastic  parameter  values  would  be  estimated  from  a  finite  observation  inter¬ 
val  by  precisely  the  formula  that  defines  the  operational  parameters. 

Operational  analysis  proceeds  to  derive  the  same  formula  given  before  for 
relating  the  proportion  of  time  spent  in  a  certain  state  to  the  operational  vari¬ 
ables  derived  above: 

p(n>  =  77  n  (W*  n  s<(fc»  o) 

u  <  =  1  ic  =  1 


Obviously,  the  same  efficient  computational  algorithms  for  calculating  the  value 
of  G  and  various  performance  measures  can  be  used  for  both  the  stochastic  and 
operational  domains,  although  both  the  variables  involved  in  the  calculation  and 
the  results  obtained  have  different  interpretations  in  the  two  domains. 

The  assumptions  required  in  operational  analysis  to  derive  the  formula 
above  are  all  testable  (at  least  in  principle)  and  are  more  understandable  than 
those  invoked  in  stochastic  analysis.  The  first  assumption  is  that  of  flow  bal¬ 
ance,  that  is  that  the  number  of  arrivals  to  a  center  is  (essentially)  the  same  as 
the  number  of  service  completions  at  the  center  during  the  observation  period. 
Flow  balance  is  guaranteed  by  ending  the  observation  interval  in  the  same  state 
in  which  it  began.  The  second  property  is  called  one-ste-p  behaviour  and  requires 
that  each  state  transition  be  the  consequence  of  the  completion  of  service  and 
movement  of  a  single  customer. 


The  other  assumptions  have  to  do  with  independence  of  certain  quantities. 
Routing  independence  (i.e.  "routing  homogeneity"[l3])  assumes  that  the  move¬ 
ment  of  a  customer  from  center  i  is  not  influenced  by  the  distribution  Df  the 
other  N  -  1  customers  among  the  M  service  centers.  Similarly,  device  indepen¬ 
dence  (i.e.  "device  homogeneity"[l3])  asserts  that  the  times  required  to  com¬ 
plete  service  to  customer  at  center  i  with  n*  customers  there  are  independent 
of  the  other  distribution  of  the  N -rti  customers  among  the  other  Af-1  service 
centers.  Obviously,  both  routing  independence  and  device  independence  are 
trivially  satisfied  in  all  observation  periods  of  a  closed  network  in  which  custo¬ 
mers  visit  alternately  two  service  centers  if  all  possible  states  are  entered.  (We 
will  indicate  how  this  last  condition  can  be  removed  later  in  this  section.)  In 
other  networks,  it  is  possible  to  determine  whether  or  not  these  properties  hold 
during  a  specific  observation  interval.  Let  n  denote  the  state  (riilng...,nTn  )  and 
rZtj  denote  the  state  reached  from  n  if  one  customer  completes  service  at  center 
i  and  moves  to  center  j.  Then  routing  independence  is  satisfied  in  an  observa¬ 
tion  interval  if  for  ail  i.j  and  n  with  1. 


2  ^  (**''  xij ) 

X 

S  E  c(x>*ik) 

x 


C  (n,  ri\j ) 

2  Cin.n^) 

M-t 


(4) 
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where  C(n, n^)  is  the  number  of  passages  observed  from  state  n  to  state  n^.  The 
left  side  of  equation  (4)  is  the  overall  ratio  of  transitions  from  device  i  to  device 
j  to  the  total  number  of  transitions  from  device  i,  while  the  right  side  is  the 
same  ratio  but  for  the  single  state  n. 


Similarly,  device  independence  is  satisfied  in  the  interval  if  for  all  i  and  n 
such  that  74^1 


w 

C4(n<) 


u 

E 


*=i 


nn) 


(5) 


where  T(n )  is  the  time  spent  in  state  n  during  the  observation  period.  The  left 
side  of  the  equation  (5)  is  the  ratio  of  the  time  spent  with  74  customers  at 
center  i  to  the  number  of  completions  at  center  i  with  74  there,  while  the  right 
side  is  the  same  ratio  for  the  single  state  n. 


If  the  flow  balance,  one  step  behaviour,  routing  independence  and  device 
independence  assumptions  are  all  satisfied  exactly  in  an  observation  period  then 
formula  (3)  gives  exact  answers  for  the  proportion  of  time  spent  in  each  system 
state.  Thus  the  validation  step  reduces  to  a  consistency  check  among  measured 
variables. 


Note  that  in  order  that  the  quantities  in  the  equations  ((4)  and  (5))  for 
routing  and  device  independence  be  well-defined,  it  is  necessary  that  all  possible 
states  be  entered  during  the  observation  period,  and  furthermore  that  all  possi¬ 
ble  completions  occur  at  each  state.  It  is  possible  to  relax  this  requirement  as 
follows.  If  equation  (4)  and  (5)  hold  after  all  occurrences  of  zero  have  been 
replaced  by  e,  and  flow  balance  and  one  step  behaviour  are  also  satisfied,  then 
the  correct  answers  for  the  proportion  of  time  spent  in  each  system  state  can 
be  obtained  from  (3)  by  taking  the  limit  as  e  approaches  zero. 

As  with  stochastic  analysis,  predicting  performance  for  future  observation 
intervals  involves  first  estimating  how  the  operational  parameter  values  will  be 
different  in  the  future  interval,  and  then  using  formula  (3)  with  the  modified 
parameter  values  to  calculate  predictions  of  the  performance  measures  for  the 
future  interval.  If  the  future  interval  proves  to  have  the  properties  flow  balance, 
one  step  behaviour,  routing  independence,  and  device  independence,  and  the 
parameter  estimates  turn  out  to  be  exact,  then  the  measures  obtained  from  the 
performance  calculation  will  also  be  exact.  This  property  of  operational  analysis 
makes  it  clear  that  parameter  estimation  is  the  difficult  part  of  performance 
prediction. 

If  the  service  rates  of  the  service  centers  are  thought  to  be  load- 
independent  then  an  additional  assumption  can  be  invoked  in  order  to  reduce 
the  number  of  operational  parameters  requiring  estimation.  The  assumption  of 
load-independent  service  times  (i.e.  "Service  time  homogeneity"  [13])  is  satisfied 
if  for  all  i  and  k 

Bj  _  Tj(k) 

Ct  Ct(k) 

where  Bit  the  busy  time  of  device  i,  and  Cit  the  number  of  service  completions  at 
device  i,  are  defined  by: 

Bi=  E  j*(*) 

fc= 1 
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and 

Ci  =  S  ci&) 

k=  1 

In  this  case,  let  S'*  =  f^/C*.  and  the  formula  reduces  to 

P(n)=  (6) 

which  is  equivalent  in  structure  to  the  stochastic  analysis  version  of  the  state 
probability  formula  when  service  centers  are  load-independent. 

Without  assuming  load-independent  service  times,  the  task  of  estimating 
how  a  service  function  will  be  altered  in  a  modified  system  is  extremely  difficult. 
The  reason  for  this  is  that,  in  general,  the  service  function  at  a  service  center  as 
defined  in  operational  analysis  depends  on  the  entire  network.  Thus  replacing 
the  device  at  center  i  with  a  faster  device  is  likely  to  affect  the  service  functions 
at  all  centers,  not  just  at  center  i.  By  making  the  assumption  of  load- 
independent  service  times,  the  parameter  estimation  problem  is  simplified. 
However,  the  predicted  performance  measures  will  be  exact  only  if  the  parame¬ 
ter  estimation  is  exact  (i.e.  if  the  system  proves  to  have  the  property  of  load- 
independent  service  times  in  the  projection  interval). 


IV.  Examples 

In  this  section,  we  present  three  examples  that  illustrate  both  strengths 
and  weaknesses  of  operational  analysis  in  its  current  state  of  development. 
Each  example  is  based  on  a  pattern  of  resource  usage  by  two  customers  that 
repeats  cyclically  an  indefinite  number  of  times.  Such  a  structure  allows  com¬ 
parison  of  the  two  approaches  although  operational  analysis  is  based  on  a  finite 
interval  while  stochastic  analysis  pertains  only  to  infinite  time  periods.  They  are 
truly  comparable  only  as  the  finite  interval  subjected  to  operational  analysis 
becomes  arbitrarily  long. 

Figure  1  shows  the  pattern  of  resource  usage  in  our  first  example.  After 
the  initial  three  time  units,  a  pattern  of  length  six  time  units  repeats  k  times  to 
form  a  time  period  of  length  6k+3  times  units.  Our  operational  analysis  of  this 
time  period  can  be  related  to  stochastic  analysis  results  as  k  becomes  arbi¬ 
trarily  large. 

Examination  of  example  1  verifies  the  fact  that  the  basic  assumptions  of 
operational  analysis  are  satisfied.  We  take  the  observation  interval  to  begin  and 
end  with  one  customer  at  each  center.  Because  routing  is  purely  cyclic,  routing 
independence  is  trivially  satisfied.  Similarly,  because  there  are  only  two 
servers,  device  independence  is  satisfied.  Figure  1  also  shows  the  calculation  of 
the  service  functions  for  the  two  centers  and  the  proportions  of  time  spent  in 
each  system  state.  By  letting  k  approach  infinity,  we  approach  a  situation  in 
which  service  times  at  the  two  devices  are  deterministically  three  and  one 
respectively.  Such  a  pattern  is  highly  inconsistent  with  the  postulation  of 
exponentially  distributed  service  times  yet  the  operational  analysis  version  of 
product  form  still  holds. 

Examination  of  the  behaviour  sequence  of  figure  1  leads  us  to  guess  that 
the  "off-line"  behavior  [13]  of  the  two  devices  would  be 
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Figure  1.  Example 
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Figure  2.  Example  1  with  faster  device  1. 
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5,(1)  =  5,(2)  =  3- E 

5 2(1)  =  5  2(2)  =  l  +  e 

If  this  is  true,  the  on-line  and  off-line  behaviors  of  the  devices  differ  substan¬ 
tially.  However,  if  the  devices  are  load-dependent,  it  is  conceivable,  although 
unlikely,  that  the  off-line  service  function  is  identical  to  the  on-line  one  observed 
in  the  interval.  Observing  the  behavior  of  a  device  while  it  is  on-line  simply  does 
not  provide  enough  information  to  determine  the  device’s  off-line  behavior,  no 
matter  what  properties  the  on-line  observation  interval  may  possess.  Hence, 
device  independence  and  routing  independence  do  not  guarantee  that  on-line 
and  off-line  service  functions  are  identical. 

Consider  now  what  happens  if  device  1  is  replaced  by  a  device  that  is  twice 
as  fast.  The  reslting  behavior  sequence  would  be  as  shown  in  figure  2.  Note  that 
5,(2)  is  quartered  rather  than  halved,  while  52(2)  is  doubled  although  device  2 
did  not  change. 

The  intuitive  approach  of  halving  each  element  in  device  one's  service 
function  while  retaining  device  two’s  service  function  leads  to  a  prediction  that 
states  (2,0)  and  (1,1)  will  be  occupied  equal  proportions  of  time  rather  than  in  a 
two  to  one  ratio.  Invoking  the  assumption  of  load-independent  service  times 
(despite  the  fact  that  it  is  not  satisfied  in  the  observation  period),  and  then  halv¬ 
ing  the  device  1  service  time  leads  to  predictions  of  proportions  of  time  9/19, 
6/19,  and  4/19  for  states  (2,0),  (1,1),  and  (0,2)  respectively. 

In  our  second  example  (see  figure  3),  the  service  times  of  device  1  have  an 
average  value  of  three,  but  a  high  variance.  Out  of  every  199  service  times  at 
device  1  194  have  length  1/2  and  the  remaining  5  have  length  100,  which  yields  a 
mean  of  3,  a  variance  of  about  235,  and  a  coefficient  of  variation  of  about  26.  All 
service  times  at  device  2  are  one.  Again  the  calculation  of  the  service  functions 
is  shown. 

As  with  the  previous  example,  consider  doubling  the  speed  of  device  one. 
In  this  case  both  components  of  device  one’s  service  function  are  essentially 
halved  (as  seems  reasonable),  but  device  two’s  service  function  is  (counter¬ 
intuitively)  also  altered  substantially. 

Table  one  summarizes  the  values  of  various  models  for  the  state  probabili¬ 
ties  both  before  and  after  the  change.  Before  the  change,  using  the  observed 
service  function  (SF)  leads,  of  course,  to  the  correct  values  for  proportions  of 
time  each  state  is  occupied.  Assuming  load-independent  (or  "homogene- 
ous"[l3])  service  times  in  operational  analysis  (HST)  or  using  a  stochastic  model 
with  exponentially  distributed  service  times  (EXP)  lead  to  identical,  mildly 
erroneous  values.  Using  a  stochastic  model  with  a  hyperexponential  service 
time  distribution  at  device  one,  where  the  variance  of  the  hyperexponential  dis¬ 
tribution  is  chosen  to  match  the  variance  of  the  observed  distribution  (HYPEXP) 
does  better  than  HST  or  EXP  but  is  not  exact. 

Predictions  for  the  situation  after  device  one’s  speed  is  doubled  are 
obtained  by  halving  the  operational  analysis  service  function  values  and  by  dou¬ 
bling  stochastic  model  service  rates.  As  can  be  seen  in  Table  I,  the  stochastic 
hyperexponential  model  and  the  operational  model  based  on  halving  the  service 
function  of  device  one  lead  to  comparably  good  predictions,  and  both  do 
significantly  better  than  the  exponential  or  homogeneous  service  time 
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Figure  3.  Example 
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predictions. 

As  is  pointed  out  by  Denning  and  Buzen[13],  a  cyclic  system  with  only  two 
servers  and  two  customers  is  guaranteed  to  satisfy  the  assumptions  of  device 
independence  and  routing  independence  in  all  observation  intervals.  Thus,  to 
assure  ourselves  that  our  two  server  example  is  not  an  isolated  special  case,  we 
examine  an  example  with  three  servers.  Again,  the  example  is  based  on  a  long 
cyclic  pattern  in  which  two  identical  customers  visit  three  servers.  Example  3 
(see  figure  4)  satisfies  device  independence,  routing  independence  and  even  ser¬ 
vice  time  independence.  The  service  times  at  each  device  follow  a  cyclic  pat¬ 
tern,  so  that  not  only  are  service  times  not  exponentially  distributed,  but  suc¬ 
cessive  service  times  are  not  even  independent.  We  assume  that  the  devices  are 
load-independent  and  that  their  behavior  is  the  same  both  on-line  and  off-line. 

In  one  cycle  of  example  3,  each  of  the  six  possible  states  is  occupied  for 
two  time  units,  and  each  state  is  left  exactly  once  in  each  possible  way  (e.g. 
state  (1,1,0)  is  left  once  by  a  service  completion  at  device  1  and  once  by  a  ser¬ 
vice  completion  at  device  2).  The  service  function  values  at  all  three  devices  for 
all  queue  lengths  are  two.  Hence,  the  system  is  "homogeneous"  in  all  the  senses 
of  operational  analysis. 

The  product  form  formula  for  proportions  of  time  spent  in  system  states 
indicates  correctly  that  each  state  is  occupied  exactly  one-sixth  of  the  time  in 
the  observation  interval.  This  example  involves  nothing  resembling  an  exponen¬ 
tial  service  time  distribution,  yet  the  system  is  homogeneous  in  every  opera¬ 
tional  analysis  sense,  and  the  product  form  formula  yields  exact  answers.  This 
invalidates  the  claim  that  homogeneity  assumptions  are  simply  exponential 
assumptions  in  disguise.  Note,  in  particular,  that  because  the  network  involves 
first-come-first-serve  service  centers  with  non-exponential  service  time  distribu¬ 
tions,  its  stochastic  analysis  solution  would  not  have  product  form  solution.  In 
this  sense  operational  analysis  product  form  is  applicable  to  systems  other  than 
those  known  to  have  stochastic  product  form  solutions. 

In  figure  5,  we  show  the  result  of  doubling  the  speed  of  device  2.  Because 
there  are  three  devices,  device  homogeneity  is  no  longer  trivially  satisfied,  and 
examination  of  the  behavior  sequence  shows  that  it  is  not  satisfied  there.  Thus, 
even  using  the  actual  observed  service  functions  for  the  three  devices,  the  pro¬ 
duct  form  formula  does  not  give  exact  proportions  of  state  occupancy  times. 
Table  2  compares  the  actual  state  occupancy  times  with  those  obtained  by  using 
the  observed  function  in  the  product  form,  and  with  those  obtained  by  using  the 
original  service  functions,  but  with  all  values  in  the  device  2  service  function 
halved.  The  two  product  form  answers  using  different  service  function  values  do 
about  equally  well  at  approximating  the  actual  proportions  of  times  states  are 
occupied  in  the  observation  period. 

There  are  two  points  of  significance  to  be  drawn  from  the  preceding  exam¬ 
ples.  They  are: 

1.  The  assumption  of  homogeneity  is  not  equivalent  to  the  assumption 
of  independent,  exponentially-distributed  service  times. 

Our  examples  have  service  time  distributions  in  which  there  are  only  one, 
two  or  three  mass  points.  While  the  service  times  observed  in  any  finite  interval 
cannot  be  proven  to  be  or  not  to  be  samples  from  a  particular  distribution,  as 
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the  number  of  cyclic  repetitions  grows,  the  plausibility  that  the  service  times 
are  drawn  from  a  distribution  with  a  few  mass  points  rather  than  from  an 
exponential  distribution  becomes  arbitrarily  great.  The  cyclic  behavior  of  our 
examples  makes  it  obvious  that  the  service  time  distributions  are  not  exponen¬ 
tial.  This  should  not  be  taken  to  indicate,  however,  that  operational  analysis 
product  form  holds  only  in  a  few  "special"  cases  without  exponentially  distri¬ 
buted  service  times.  In  fact,  in  any  behavior  sequence,  redistributing  the  time 
spent  in  any  way  such  that  the  order  of  state  transitions  is  unchanged  and  the 
total  time  spent  in  each  state  is  unchanged  alters  neither  the  values  of  the 
operational  variables  nor  the  validity  of  the  operational  analysis  product  form. 
These  examples  suffice  to  show  that  homogeneity  is  not  simply  a  hidden  assump¬ 
tion  of  exponentially  distributed  service  times.  In  particular,  intervals  that 
include  transient  or  cyclic  behaviour  can  satisfy  homogeneity,  although  they 
clearly  violate  such  assumptions  as  equilibrium  and  independence  of  successive 
service  times  or  successive  routing  decisions. 

2.  Homogeneity  of  a  system  is  highly  sensitive  to  the  kinds  of  changes 

that  one  wishes  to  investigate  using  queueing  network  models. 

Observing  a  system  to  be  homogeneous  in  a  specific  time  interval  in  no  way 
guarantees  that  it  would  also  have  been  homogeneous  in  a  slightly  altered  situa¬ 
tion  in  which,  for  example,  one  server’s  speed  is  doubled  (so  that  its  service 
times  are  halved).  Thus,  if  homogeneity  is  a  mandatory  assumption  in  opera¬ 
tional  analysis,  then  it  is  seldom  applicable.  There  is  a  need  to  relax  the  idea  of 
homogeneity  so  that  it  is  a  relative  rather  than  an  absolute  property  of  a  system 
in  an  interval.  We  will  elaborate  on  this  topic  in  section  V. 


V.  Discussion 

In  light  of  the  examples  of  the  previous  section,  we  now  state  our  current 
view  of  the  roles  of  operational  analysis  and  stochastic  analysis. 

Relevance  to  actual  systems.  The  fact  that  operational  analysis  is  based 
on  observable  quantities  and  testable  assumptions  makes  it  easier  to  relate  to 
system  measurements. 

Understandability.  Operational  analysis  can  be  taught  to  and  understood 
by  persons  who  typically  work  with  large  computer  systems. 

Breadth  of  applicability.  Operational  analysis  does  not  require  equili¬ 
brium  or  stochastic  independence  of  successive  service  times  and  routing  deci¬ 
sions,  assumptions  that  are  clearly  not  satisfied  in  actual  systems.  Thus,  if  it 
can  be  shown  that  the  operational  analysis  assumptions  are  approximately 
satisfied  in  actual  systems  and  that  good  approximate  answers  are  obtained 
when  assumptions  are  approximately  satisfied,  then  the  observed  success  of 
equations  (1)  and  (2)  in  modelling  actual  computer  systems  will  be  better 
explained. 

Ease  of  Parameter  Estimation.  Because  service  functions  are  influenced 
by  all  changes  to  the  system,  it  is  difficult  to  estimate  how  a  given  service  func¬ 
tion  observed  in  one  interval  is  likely  to  be  changed  by  an  anticipated 
modification  to  the  system.  Stochastic  parameters  generally  more  closely 
relate  to  the  internal  structure  of  the  system,  so  the  parameter  estimation  task 
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is  more  straightforward. 

Testability  of  Assumptions.  Most  of  the  assumptions  of  stochastic  analysis 
can  be  neither  verified  nor  disproven  in  any  finite  period.  While  the  assumptions 
of  operational  analysis  can  in  principle  be  tested  in  finite  time  intervals,  it 
seems  clear  that  most  of  the  assumptions  are  extremely  unlikely  to  be  even 
approximately  satisfied  in  short  time  periods.  In  long  time  periods  it  is 
extremely  unlikely  that  they  will  be  satisfied  exactly.  Although  testing  the 
operational  analysis  assumptions  is  possible  in  principle,  its  practicality  is  also 
highly  questionable  due  to  the  extremely  large  number  of  quantities  to  be  meas¬ 
ured.  For  example,  testing  routing  independence  involves  the  quantities 
Cin.nq),  of  which  there  are  approximately  five  million  in  a  system  with  ten  cus¬ 
tomers  and  ten  service  centers. 

Operational  analysis  remains  a  young  approach  to  performance  evaluation. 
The  directions  in  which  it  may  be  extended  are  numerous.  One  example  is  the 
development  of  the  operational  analog  to  an  M/G/l  queue  or  queueing  networks 
involving  service  centers  with  non-exponential  service  time  distributions. 
(Current  operational  analysis  results  are  the  analogs  of  birth/death 
systems, including  M/M/l,  and  networks  of  exponential  servers.) 

Because  operational  analysis  is  based  on  assumptions  that  can  be  tested 
but  that  are  very  unlikely  to  be  satisfied  exactly  in  any  finite  time  period,  it  is 
very  important  to  develop  a  means  of  dealing  with  "fuzzy  homogeneity"  or  situa¬ 
tions  in  which  the  various  independence  assumptions  are  satisfied  within  some 
tolerance.  A  desirable  result  would  be  an  expression  of  how  large  an  error  might 
exist  in  the  product  from  solution  in  terms  of  a  measure  of  how  well  the  indepen¬ 
dence  assumptions  are  satisfied. 
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Workload  Characterization  In  Computer 

Systems 
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Abstract 

Workload  characterization  is  one  of  the  most  necessary  and  difficult  tasks 
in  the  evaluation  of  computer  system  performance.  This  task  can  be  made 
easier  if  one  can  identify  the  natural  groups  of  similar  jobs  in  the  workload. 
These  groups  will  likely  be  easier  to  analyze  and  understand  individually  than 
the  overall  workload  as  a  whole.  They  can  also  be  used  as  workload  classes  in 
the  construction  of  workload  models,  the  generation  of  charging  and  scheduling 
schemes,  and  even  for  prediction  of  future  workload  trends. 

In  the  context  of  a  larger  investigation  of  the  use  of  certain  multivariate 
statistical  tools  in  workload  characterization,  cluster  analysis  was  examined  for 
the  purpose  described  above.  However,  within  cluster  analysis  there  are  many 
available  algorithms.  This  paper  describes  the  general  theory  and  basic  ap¬ 
proaches  of  cluster  analysis,  and  then  presents  and  evaluates  six  simple  algo¬ 
rithms  using  actual  workload  data.  We  demonstrate  their  differences,  in  terms 
of  computational  requirements,  the  clusters  generated,  and  the  workload  insight 
provided. 

We  conclude  that  cluster  analysis  is  a  useful  approach  for  identifying  the 
component  job  groups  of  a  workload,  and  provide  some  guidelines  for  the  intelli¬ 
gent  choice  of  clustering  algorithms.  We  also  conclude  that  it  is  desirable  for 
the  analyst  to  compare  the  results  of  more  than  one  algorithm,  and  to  interpret 
the  generated  clusters  in  the  context  of  his  own  knowledge  about  the  workload. 


"This  paper  is  extracted  from  an  M.Sc.  thesis  entitled  ’An  Investigation  Into 
Workload  Characterization’,  in  the  Department  of  Computer  Science,  University 
of  Toronto,  May,  1979. 
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1.  Introduction 

The  difficult  process  of  workload  characterization  is  necessary  for  the  pur¬ 
poses  of  evaluating,  modelling,  and  improving  computer  system  performance. 
In  characterizing  workloads,  the  system  analyst  often  wishes  to  classify  user 
jobs  into  classes  so  that  jobs  within  the  same  class  are  in  some  sense  more  simi¬ 
lar  to  each  other  than  to  those  in  different  classes.  For  example,  the  construc¬ 
tion  of  natural  or  sythetic  benchmarks,  and  the  development  of  queueing  net¬ 
work  models  of  system  performance  all  require  the  identification  of  classes  of 
jobs  with  similar  resource  usage  characteristics.  In  addition,  computer  centre 
management  need  to  define  job  classes  for  charging  and  accounting  purposes, 
and  internal  systems  need  them  for  scheduling  purposes  (e.g.,  transaction 
classes  in  IMS,  and  performance  groups  in  MVS). 

In  the  field  of  multivariate  statistics,  cluster  analysis  has  long  been  used 
for  the  general  problem  of  separating  N  data  units,  each  measured  on  p  vari¬ 
ables,  into  distinct  classes  or  "clusters".  Recently,  it  has  shown  promise  in  com¬ 
puter  workload  classification  [AGRA76],  where  the  units  clustered  are  jobs,  the 
variables  measured  are  computer  resource  usages,  and  the  clusters  generated 
correspond  to  workload  classes.  Unfortunately,  cluster  analysis  is  not  a  single 
integrated  technique;  "rather  it  is  an  umbrella  term  for  a  loose  collection  of 
heuristic  procedures  and  diverse  elements  of  applied  statistics"  [ANDE73]. 
There  are  a  variety  of  available  algorithms,  each  of  which  will  generate  a  valid, 
but  possibly  different,  set  of  workload  classes. 

This  paper  reports  the  results  of  a  comparative  study  of  some  simple  clus¬ 
tering  algorithms,  which  was  undertaken  as  part  of  a  larger  investigation  of  the 
use  of  some  statistical  tools  in  workload  characterization  [CHU79].  Their  perfor¬ 
mance  characteristics  on  actual  workload  data  are  examined  from  many  points 
of  view,  in  order  to  show  the  workload  analyst  how  they  work,  their  relative  ad¬ 
vantages  and  disadvantages,  and  the  type  of  insight  they  can  give  him  about  his 
workload.  To  our  knowledge,  such  a  comparative  study  using  computer  work¬ 
load  data  has  not  been  previously  reported.  Our  objective  is  not  necessarily  to 
choose  a  single  "best"  algorithm.  Rather,  the  features  of  each  one  are  present¬ 
ed,  emphasizing  those  deemed  most  important  in  the  workload  context.  It  is 
hoped  that  these  results  will  help  the  analyst  in  intelligently  choosing  and  apply¬ 
ing  cluster  analysis  algorithms  for  his  own  purposes.  In  the  next  two  sections, 
before  proceeding  to  the  actual  algorithm  comparisons,  we  briefly  introduce  the 
basic  general  theory  of  cluster  analysis,  and  the  workload  data  used. 


2.  Introduction  to  Gins  ter  Analysis 

The  term  "cluster"  is  easy  to  grasp  intuitively;  it  refers  to  a  natural  group 
of  similar  jobs  in  the  data.  However,  finding  clusters  in  real  data  requires  a  pre¬ 
cise  definition  of  two  basic  concepts,  which  are  outlined  below. 

First,  the  way  of  measuring  the  "distance"  or  similarity  between  each  pair 
of  jobs  must  be  defined.  It  is  common  to  view  the  N  jobs  as  points  in  space,  with 
axes  defined  by  the  p  variables.  One  common  example  of  a  similarity  measure 
between  two  jobs  is  the  Euclidean  distance  between  their  points  in  this  space. 
This  is  the  measure  used  in  this  paper.  Discussions  of  other  possible  measures 
can  be  found  in  [C0RM71.EVER74,  and  ANDE73],  among  others. 
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Second,  the  criterion  for  deciding  which  jobs  are  assigned  to  which  cluster 
must  be  given.  This  usually  involves  stating  how  to  measure  the  similarity 
between  a  job  and  a  cluster  of  jobs,  or  between  two  clusters  of  jobs.  For  exam¬ 
ple,  a  job  may  be  assigned  to  a  particular  cluster  because  it  is  most  similar  to 
that  cluster’s  mean,  or  because  the  most  similar  job  to  it  in  the  data  also  be¬ 
longs  to  that  cluster.  This  decision  determines  the  eventual  cluster  types  and 
shapes.  When  we  refer  to  different  clustering  algorithms,  we  are  essentially 
referring  to  different  clustering  criteria. 

Most  of  the  commonly  used  clustering  algorithms  in  the  literature  fall  basi¬ 
cally  into  two  major  types:  hierarchical  and  partition.  Hierarchical  methods 
may  be  subdivided  into  agglomerative  (bottom-up)  and  divisive  (top-down) 
methods.  In  agglomerative  methods,  each  of  the  N  jobs  starts  as  a  separate 
cluster.  These  are  then  merged  into  progressively  larger  clusters,  ending  up 
with  one  cluster  of  N  jobs.  Divisive  methods  work  in  the  reverse  direction.  Both 
types  of  results  are  representable  by  a  two-dimensional  tree  diagram,  known  as 
a  dendogram  (Figure  1).  At  each  of  the  N  —  1  stages,  the  most  ''efficient"  division 
or  merge  is  performed,  with  respect  to  the  pre-defined  clustering  criterion.  Be¬ 
cause  N  —  1  levels  of  clustering  are  presented,  there  is  the  problem  of  selecting 
the  desired  number  of  clusters.  In  Section  4  we  shall  define  a  special  function  to 
assist  us  in  this  respect.  Another  problem  is  that  the  results  of  early  stages  are 
irrevocable,  and  therefore  affect  the  outcomes  of  the  later  stages,  which  may 
therefore  represent  only  a  local  optimum  of  the  clustering  criterion. 

Interest  usually  centres  on  agglomerative  techniques:  divisive  ones  are  less 
common.  The  general  agglomerative  procedure  starts  with  computation  of  an  AT 
x  N  matrix  5  of  similarity  values  between  all  pairs  of  jobs.  The  steps  are: 

1)  Begin  with  N  clusters  of  one  job  each 

2)  Find  the  best  similarity  value  in  S,  say  between  clusters  p  and  q 

3)  Merge  clusters  p  and  q,  and  update  S 

4)  Repeat  steps  2)  and  3)  N-l  times. 

The  agglomerative  methods  differ  basically  in  how  steps  2)  and  3)  are  defined.  A 
good  preliminary  evaluation  of  some  of  these  methods  may  be  found  in 
[CUNN72]. 

Partition  methods,  as  opposed  to  hierarchical  methods,  do  not  begin  with  a 
matrix  of  similarities,  but  rather  work  with  the  actual  data  ( N  jobs  measured  on 
p  variables).  These  generally  assume  an  initially  specified  number  of  clusters. 
The  usual  approach  is  for  the  user  to  supply  the  p  coordinates  of  the  initial 
mean  point  (centroid)  for  each  cluster.  These  centroids  are  called  seeds.  Then 
a  pass  is  made  through  the  data,  taking  each  job  in  turn  and  calculating  its  simi¬ 
larity  to  each  seed.  Then,  the  clustering  criterion  is  usually  simply  to  assign 
each  job  to  the  nearest  cluster  seed.  The  seed  coordinates  can  be  recomputed 
after  every  allocation,  or  be  kept  fixed  until  the  pass  is  complete.  Some 
methods  allow  the  number  of  clusters  to  change.  For  example,  if  two  seeds  be¬ 
come  "too  similar",  the  clusters  may  be  merged,  or  if  a  job  is  "too  dissimilar" 
from  all  the  seeds,  it  may  become  the  seed  for  a  new  cluster.  However,  there  is 
no  simple  method  for  accurately  determining  the  threshold  similarity  values  for 
making  these  decisions. 

The  other  basic  partition  approach  is  to  choose  some  initial  partition  of 
the  jobs  into  clusters.  Then  as  before,  each  job  is  examined  and  possibly  reas- 
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signed  to  a  new  cluster,  according  to  a  chosen  criterion. 

For  all  partition  methods,  many  passes  through  the  data  may  be  neces¬ 
sary;  the  user  provides  a  stopping  rule,  usually  expressed  in  terms  of  the 
number  of  reassignments  per  data  pass.  Alternative  criteria  are  the  stability  of 
the  seed  points,  or  lack  of  improvement  in  the  chosen  criterion.  These  methods 
can  be  very  fast  and  cheap,  as  we  shall  see  in  Section  6.  However,  there  is  no 
proven  simple  method  for  generating  good  initial  seeds  or  partitions  from 
scratch  (see  [ANDE73.D0M075]),  or  even  deciding  the  initial  number  of  clusters. 
Slow  convergence  is  also  a  potential  problem,  although  some  methods  can  be 
proved  to  converge  eventually  [ANDE73,  Chapter  7]. 

Of  the  other  clustering  algorithms  that  exist,  most  can  be  classified  rough¬ 
ly  into  two  categories:  density  or  mode-seeking  algorithms,  and  clumping  algo¬ 
rithms  [EVER74].  The  former  look  for  regions  of  dense  concentrations  of  jobs  in 
the  variable  space,  and  the  latter  permit  overlapping  clusters.  However,  as  this 
was  only  a  preliminary  study,  these  algorithms  were  not  included. 

One  final  important  consideration  is  the  scaling  of  data.  If  the  variables 
used  have  very  unequal  scales  of  measurement,  then  the  amalgamation  of  their 
diverse  units  (CPU  seconds,  lines  printed,  and  so  on)  into  a  single  meaningful 
measure  of  job  similarity  will  be  difficult;  a  relatively  minor  change  in  one  vari¬ 
able  may  dominate  a  relatively  major  one  in  another.  The  solution  used  in  this 
paper  is  to  standardize  each  variable  to  zero  mean  and  unit  variance.  This  gives 
the  variables  much  more  similar  ranges  of  values,  and  is  widely  recommended 
[EVER74].  Other  suggestions  for  data  scaling  can  be  found  in  [AGRA76]  and 
[ANDE73,  Chapters  3  and  5], 


3.  The  Workload  Used 

The  workload  data  used  was  obtained  from  a  job-oriented  software  ac¬ 
counting  monitor  called  AUDITRAIL  at  the  University  of  Toronto  [CHU79],  Of  the 
many  variables  reported  for  each  batch  job,  the  following  seven  were  used: 
ELAPSED  TIME,  CPU  TIME,  IOWAIT  TIME,  CARDS  READ.  LINES  PRINTED,  JOB  STEPS, 
and  TAPE  MOUNTS.  These  variables  were  the  ones  that  were  of  interest  from  a 
performance  viewpoint;  they  either  were  measures  of  system  resources  that 
jobs  used,  or  criteria  on  which  jobs  were  charged  by  the  installation. 

These  batch  jobs  are  classified  into  3  classes  by  the  university  computer 
centre:  A,  B,  and  W.  Class  W  is  a  class  of  student  jobs,  generally  from  introducto¬ 
ry  computing  courses.  These  jobs  are  small  and  receive  high  priority  service.  In 
return  for  this  service,  the  jobs  are  limited  in  the  resources  they  can  use:  30 
seconds  elapsed  time,  5  seconds  of  toted  CPU  time,  eind  600  lines  of  execution 
output  (not  including  source  listings).  These  jobs  cannot  mount  tapes  or  create 
permanent  disk  files. 

Class  A  is  a  class  of  slightly  larger  batch  jobs,  with  the  following  maximum 
limits:  5  minutes  of  toted  CPU  time  plus  I/O  time,  15000  output  lines,  2000 
punched  cards,  etnd  250K  bytes  of  memory.  They  are  not  permitted  to  mount 
tapes. 

Class  B  is  a  class  of  large  batch  jobs  that  either  are  estimated  to  exceed 
the  execution  limits  of  class  A,  or  require  tape  mounts. 
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A  one-hour  period  containing  631  completed  jobs  was  selected  as  our  test 
workload,  because  it  represented  a  period  of  heavy  load  on  the  system  and  con¬ 
tained  a  fairly  typical  mix  of  small  and  large  jobs,  as  well  as  a  large  range  of 
values  for  all  the  variables  (see  Table  1)  [CHU79,  Chapter  10].  AIL  seven  variables 
had  positively  skewed  distributions;  there  was  typically  a  very  large  proportion 
of  small-valued  jobs,  and  a  few  very  large-valued  jobs. 


4.  Comparison  Criteria 

We  now  present  the  criteria  on  which  the  selected  clustering  algorithms 
will  be  compared.  First,  the  algorithms  will  be  compared  on  their  implementa¬ 
tion  costs.  Because  the  memory  and  CPU  are  usually  the  major  cost  concerns, 
the  algorithms’  basic  memory  requirements  and  run-time  complexities  will  be 
examined. 

Second,  we  shall  examine  the  job  clusters  produced  by  each  method  and 
the  insight  they  give  us  into  the  workload.  Each  algorithm  has  intrinsic  charac¬ 
teristics  that  affect  the  type  of  clusters  it  is  likely  to  find.  We  can  examine  the 
sets  of  clusters  produced  for  points  of  agreement  and  disagreement,  as  well  as 
for  useful  information  provided.  They  will  be  evaluated  with  respect  to  the 
known  characteristics  of  our  workload  and  to  the  installation-defined  classes. 

Unfortunately,  this  second  comparison  criterion  does  not  allow  us  to  quan¬ 
tify  the  goodness  of,  or  difference  between,  cluster  sets.  In  performance  evalua¬ 
tion,  we  are  usually  interested  in  the  workload  class  means,  to  be  used  for  exam¬ 
ple  as  summary  statistics  or  in  the  rapidly  growing  field  of  queueing  network 
modelling  of  computer  system  performance,  where  workload  classes  of  jobs  are 
usually  characterized  by  their  mean  characteristics.  Therefore  we  want  each 
job  to  be  classified  so  as  to  be  as  dost  as  possible  to  its  cluster  mean  (over  all 
variables). 

As  mentioned  in  Section  2,  [CHU79,  Section  6.8],  and  [EVER74],  we  can 
define  a  function  to  quantify  the  goodness  of  a  set  of  clusters  based  on  cluster 
means.  Hereafter  known  as  the  frace  function  [D0M075],  the  function  chosen  in 
this  paper  focusses  on  the  contribution  of  each  job  to  the  dispersion  of  resource 
usage  values  within  its  own  cluster.  The  total  dispersion  within  a  cluster  k  is: 

4  =  E  S  cJk)2 

/= 1 <=1 

where  Xy*  =  the  value  of  job  i  on  variable  j  (in  cluster  fc),  and 
cjk  =  the  mean  of  variable  j  (in  cluster  k). 

Summing  this  value  for  all  clusters  gives  the  total  dispersion  about  cluster 
means  in  all  the  data: 

E  =  E 

*=  i 


Minimizing  this  quantity  is  equivalent  to  producing  clusters  that  are  com¬ 
pact,  with  small  variations  about  their  means,  over  all  variables.  To  normalize 
this  value,  we  divide  E  by  the  total  dispersion  of  the  jobs  about  the  overall  popu¬ 
lation  mean: 

E  E  (*</-c,)2 

j=l i= 1 
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TABLE  1 


WORKLOAD  CHARACTERISTICS 

TOTAL  WORKLOAD:  631  JOBS 

VARIABLE 

MEAN 

c.v. 

MINIMUM 

MAXIMUM 

ELAPSED  TIME* 

33.70 

2.74 

.15 

950.98 

CPU  TIME* 

1.79 

1.88 

.01 

29.84 

IOWA IT  TIKE* 

4.12 

2.69 

0 

0 

• 

163.33 

CARDS  READ 

159.27 

2.21 

2 

4841 

LINES  PRINTED 

390.84 

3.33 

0 

20522 

JOB  STEPS 

CO 

CN 

• 

2.34 

0 

7 

TAPES 

.028 

7.32 

0 

3 

*  in  seconds 

BY  CLASS: 

CLASS  A:  116 

JOBS 

VARIABLE 

MEAN 

C.V. 

MINIMUM 

MAXIMUM 

ELAPSED  TIME 

108.75 

1.21 

7.35 

781.76 

CPU  TIME 

4.61 

1.09 

.25 

19.33 

I  aw  A  IT  TIME 

12.69 

1.66 

.46 

163.33 

CARDS  READ 

351.15 

2.10 

6 

4841 

LINES  PRINTED 

713.86 

1.77 

0 

9751 

JOB  STEPS 

1.74 

.62 

1 

7 

TAPES 

0.00 

.00 

0 

0 

(continued  on  next  page) 
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TABLE  1 

(continued) 

CUSS  B: 

17  JOBS 

VARIABLE 

MEAN 

C.V. 

MINIMUM 

MAXIMUM 

ELAPSED  TIME 

306.51 

.86 

46.25 

950.98 

CPU  TIME 

9.03 

1.13 

.63 

29.84 

IOWA IT  TIME 

23.72 

.88 

2.47 

67.73 

CARDS  READ 

188.12 

2.17 

4 

1630 

LINES  PRINTED 

3^35.92 

1.90 

101 

20522 

JOB  STEPS 

2.24 

.49 

1 

5 

TAPES 

1.06 

.71 

0 

3 

CUSS  W:  498 

JOBS 

VARIABLE 

MEAN 

C.V. 

MINIMUM 

MAXIMUM 

EUPSED  TIME 

6.91 

.64 

.15 

28.27 

CPU  TIME 

.89 

.95 

.01 

4.07 

IOWA IT  TIME 

1.46 

.91 

.00 

8.63 

CARDS  READ 

113.59 

1.07 

2 

1379 

LINES  PRINTED 

211.66 

.77 

9 

1386 

J03  STEPS* 

0.00 

.00 

0 

0 

TAPES 

0.00 

.00 

0 

0 

♦AUDITRAIL  reported  no  job  steps  for  class  W  jobs,  because  the  operating 
system  routine  to  handle  them  was  brought  up  only  once  in  the  morning 
for  the  entire  day.  Therefore,  the  overhead  in  initiating  a  class  W 
job  was  trivial  compared  to  that  for  a  class  A  or  class  B  job  step. 


Thus,  the  function  ranges  from  a  maximum  of  one  (clustering  gains  us  nothing 
compared  to  leaving  all  the  jobs  in  one  cluster)  to  a  minimum  of  zero  (every 
cluster  is  exactly  described  by  its  mean). 

For  example,  in  agglomerative  methods,  this  function  starts  at  zero,  and 
grows  steadily  as  clusters  are  merged.  Dramatic  increases  have  been  shown 
when  two  well-separated,  compact  clusters  are  merged  into  a  single  widely- 
dispersed  one,  and  so  this  function  can  help  identify  good  and  bad  sets  of  clus¬ 
ters  (e.g.,  in  choosing  an  appropriate  stage  to  examine  in  a  dendogram).  If  our 
comparisons  are  on  the  same  data,  then  the  denominator  will  be  fixed,  and  so 
the  numerator  will  be  the  most  important  consideration.  In  comparisons  of  two 
values,  the  larger  value  will  reflect  a  set  of  clusters  that  are  more  internally 
dispersed,  have  less  meaningful  mean  values  of  resource  usage,  and  contain 
more  dissimilar  jobs  within  each  cluster.  This  function  will  be  used  in  Section  7 
when  comparing  the  clusters  produced  by  each  algorithm. 


5.  The  Clustering  Algorithms 

We  now  present  six  clustering  algorithms  for  comparison.  An  exhaustive 
investigation  of  cluster  algorithms  would  be  impossible.  We  have  limited  the 
study  to  a  set  of  algorithms  that  are  relatively  simple  to  understand  and  use. 
They  all  use  intuitively  reasonable  clustering  criteria  for  classifying  jobs  so  that 
jobs  within  each  cluster  are  as  similar  to  each  other  as  possible. 

For  detailed  descriptions  and  computer  programs  of  the  first  five  methods, 
the  reader  is  referred  to  [ANDE73,  Chapters  6  and  7].  The  sixth  method  is 
described  in  [LEFK76]  but  had  to  be  programmed  specially. 

We  begin  with  a  hierarchical  agglomerative  method  proposed  by  Ward  and 
henceforth  known  as  WARD1.  The  clustering  criterion  at  each  stage  is  simply  to 
merge  those  two  clusters  that  give  the  smallest  increase  in  our  trace  function. 
We  have  already  described  the  desirability  of  this  result. 

The  second  algorithm,  henceforth  known  as  WARD2,  is  a  variant  of  WARD1, 
where  the  clustering  criterion  at  each  stage  is  to  minimize  the  variance  in  the 
new  cluster  formed.  That  is,  for  the  k cluster,  containing  n*.  jobs,  WARD1  tries 
to  minimize  2?*  (the  total  squared  deviation  of  jobs  from  the  cluster  mean),  but 
WARD2  tries  to  minimize  E^/n^  (the  average  squared  deviation  of  jobs  from  the 
cluster  mean). 

Consider  the  effect  of  the  denominator  nk  on  the  proposed  merger  of  two 
well-separated  clusters,  each  with  many  jobs.  The  result  of  merger  will  be  one 
big  cluster  with  large  dispersion  of  job  values  about  its  mean  (Ek),  which  seems 
undesirable.  WARD1  would  probably  not  merge  these  two  clusters,  but  WARD2 
might,  if  the  total  number  of  jobs  ( nk )  was  large  enough.  Therefore,  although 
the  idea  of  defining  clusters  with  small  variances  may  sound  intuitively  appeal¬ 
ing  for  our  purposes,  it  remains  to  be  seen  how  consideration  of  the  number  of 
jobs  in  each  cluster  will  affect  the  clusters  produced. 

The  third  algorithm,  known  as  single  linkage  (SL),  is  another  agglomerative 
method,  which  was  chosen  mainly  because  it  is  very  simple  and  popular.  In  fact, 
it  is  the  only  algorithm  offered  by  the  BMDP  statistical  package.  The  distance 
between  two  clusters  that  are  being  considered  for  merger  is  defined  by  this 
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method  as  the  distance  between  their  two  closest  member  jobs  (see  Figure  2). 
The  attractiveness  of  this  is  that  for  each  cluster,  every  job  is  more  similar  to 
some  other  job  in  the  same  cluster  than  to  any  job  outside  the  cluster. 

The  fourth  algorithm,  known  as  complete  linkage  (CL),  is  opposite  to  SL,  in 
that  mergers  of  clusters  are  based  on  the  distance  between  their  most  distant 
members.  That  is,  all  pairs  of  jobs  in  the  new  cluster  are  at  least  as  close  (simi¬ 
lar)  to  each  other  as  this  maximum  distance.  This  is  the  only  method  provided 
in  the  SAS  statistical  package.  The  attractiveness  of  this  method  is  that  it 
minimizes  the  range  of  resources  used  by  jobs  in  each  cluster;  that  is,  it  bounds 
the  "diameter"  of  each  cluster  in  the  variable  space  (see  Figure  2). 

The  fifth  algorithm,  known  as  KMEANS,  was  proposed  by  MacQueen[l967]. 
It  is  a  partition  method,  which  accepts  fc  initial  cluster  seeds  (class  means),  and 
then  assigns  each  job  to  the  cluster  with  the  nearest  mean.  The  means  are 
recomputed  after  every  such  assignment,  (except  during  the  final  pass  through 
the  data,  in  which  the  seeds  are  kept  fixed  until  the  end).  MacQueen’s  original 
algorithm  assumed  that  only  two  passes  through  the  data  were  required  to  yield 
a  reasonably  stable  allocation  of  jobs  to  clusters.  In  our  experiments,  this  res¬ 
triction  was  removed.  A  number  of  other  partition  methods  differ  from  KMEANS 
only  in  minor  details  (e.g.,  see  [ANDE73,  Chapter  7]).  As  mentioned  in  Section  2, 
some  complex  ones  allow  for  variation  in  the  number  of  clusters  produced,  but 
were  judged  to  be  too  difficult  to  use  effectively,  requiring  too  much  prior  infor¬ 
mation  to  be  of  general  interest  in  a  preliminary  study.  There  are  also  other 
partition  methods  that  try  to  optimize  different  criteria  [ANDE73,  Section  7.4], 
but  KMEANS  is  commonly  discussed  and  simple.  Therefore  KMEANS  is  the  only 
partition  method  used. 

Finally,  as  an  example  of  some  newer  and  more  revolutionary  approaches, 
a  method  proposed  by  Lefovitch  was  tested.  This  method  is  difficult  to  classify 
precisely;  it  is  hierarchical  and  divisive,  but  does  not  use  similarity  measures 
between  jobs.  Because  it  does  not  resemble  the  traditional  approaches 
described  in  Section  2,  we  briefly  explain  it  below.  For  details  and  examples  of 
the  method,  see  [LEFK76]. 

For  data  measured  on  p  variables,  p  new  variables  known  as  "principal 
components"  can  be  defined,  which  are  linear  combinations  of  the  original  vari¬ 
ables.  For  details  of  this  process  see  [HARM76]  or  [LAWL63].  These  components 
can  easily  be  computed  because  they  are  the  orthogonal  eigenvectors  of  the  p 
by  p  correlation  matrix  of  the  data.  Two  properties  of  these  components  are 
especially  significant  for  this  discussion. 

First,  a  value  or  "score"  for  each  job  on  each  component  can  be  calculated 
as  a  linear  combination  of  the  job’s  standardized  original  variable  values. 

Second,  the  components  are  defined  to  account,  in  successively  optimal 
fashion,  for  as  much  of  the  variance  in  the  original  data  as  possible.  That  is,  the 
first  component  accounts  for  the  largest  amount  of  overall  variance,  the  second 
accounts  for  a  smaller  amount  of  the  remaining  unexplained  variance,  and  so 
on,  until  all  the  variance  is  accounted  for  by  p  components. 

The  sixth  clustering  algorithm  works  on  our  data  in  the  following  way.  It 
calculates  the  seven  principal  components  and  the  score  of  each  job  on  each 
component.  It  assumes  that  each  component  defines  an  underlying  property  of 
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the  jobs,  on  which  the  positive-scoring  jobs  and  negative-scoring  jobs  can  be  use¬ 
fully  divided  into  two  natural  groups.  Therefore,  it  looks  only  at  the  signs  of  the 
principal  component  scores  for  each  job.  Because  the  components  are  succes¬ 
sively  defined  in  optimal  fashion,  we  consider  them  in  order,  leading  to  a 
hierarchical  scheme. 

This  algorithm  was  included  because  it  has  many  interesting  characteris¬ 
tics.  It  is  the  only  divisive  method  chosen.  Its  approach  to  clustering  is  com¬ 
pletely  unique.  Like  partition  methods,  it  does  not  use  a  matrix  of  job  similari¬ 
ties,  resulting  in  small  run  time  and  memory  requirements.  Yet,  like 
agglomerative  methods,  it  conveniently  gives  many  cluster  sets  in  one  run,  in 
dendogram  form.  Because  its  basic  step  of  finding  principal  components  is 
essentially  an  eigenvector  problem,  it  runs  fairly  quickly,  using  the  numerical 
matrix  technique  of  "singular  value  decomposition".  This  sixth  method,  which 
we  call  SVD,  was  originally  presented  as  a  breakthrough,  because  of  its  speed.  In 
the  experiments  to  follow,  we  shall  be  investigating  this  claim,  as  well  as  the  vali¬ 
dity  of  this  approach  to  defining  meaningful  workload  classes. 

It  should  now  be  obvious  that  there  are  many  possible  ways  of  trying  to 
uncover  natural  groups  of  similar  jobs  in  workload  data.  Given  the  basic  outlines 
of  the  methods  chosen,  we  now  begin  our  investigation  with  a  comparison  of 
their  implementation  costs. 


6.  Implementation  Comparisons 

In  this  section  we  briefly  examine  the  basic  average  operation  counts  and 
main  memory  requirements  for  each  algorithm.  These  can  be  very  important  if 
the  computer  facilities  available  are  limited  or  expensive  to  use.  We  shall  show 
that  certain  algorithms  have  inherent  characteristics  that  allow  faster,  cheaper 
implementations  than  others.  Only  the  major  results  are  presented;  more  detail 
is  available  in  the  reference  for  each  method.  For  all  methods,  we  begin  with 
data  for  N  jobs  on  p  variables. 

We  first  consider  the  basic  agglomerative  approach  used  by  SL  and  CL.  For 
a  detailed  description,  see  [ANDE73,  Chapter  6].  The  basic  steps  were  outlined 
in  Section  2.  Most  of  the  run  time  is  taken  up  by  three  steps: 

1)  initial  generation  of  the  lower  half  of  the  N  by  N  similarity  matrix, 
S, 

2)  searching  5  at  each  of  the  N- 1  stages  for  its  smallest  (best)  entry 
(to  decide  which  clusters  to  merge),  and 

3)  updating  similarities  in  5  after  every  merger. 

The  operations  required  for  step  2)  above  can  be  reduced  if  we  use  a  separate 
vector  to  store  the  minimum  entry  for  each  row  of  S’.  Then,  at  each  stage,  we 
need  only  search  a  vector  of  length  N,  rather  than  half  of  an  AT  by  AT  matrix. 
However,  some  of  these  minima  will  have  to  be  updated  after  every  merger.  The 
expected  operation  counts  for  these  algorithms  are  given  in  Table  2  in  terms  of 
comparisons  (searches  for  minima)  of  similarity  values,  and  computations 
(updates)  of  similarity  values.  Basically,  this  is  an  order  N2  approach. 

The  basic  storage  requirement  is  the  lower  triangular  half  of  the  matrix,  S, 
plus  the  vector  of  row  minima  (see  Table  2).  This  is  called  the  stored  matrix 
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and  (27"P)N  words  for  WARD1  and  WARD2. 

***  The  value  depends  on  whether  the  job  data  are  stored  in  main  memory,  or  auxiliary  storage.  In  the  former 
case,  NP  is  the  size  of  the  data  matrix.  In  the  latter  case,  N  is  the  length  of  the  cluster  membership 

list  of  the  jobs.  Also  note  that  for  KMEANS,  the  seeds  are  not  updated  during  the  last  data  pass. 
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approach. 

This  approach  i3  limited  to  fairly  small  problems  because  the  size  of  the 
similarity  matrix  can  soon  become  larger  than  the  original  data  itself  (Table  3). 
The  alternative  is  to  store  only  the  original  data,  and  repeatedly  compute  simi¬ 
larities  from  it.  This,  however,  is  not  feasible  for  SL  and  CL,  because  every  time 
we  wish  to  compute  the  similarity  between  two  clusters  to  see  if  they  should  be 
merged,  we  would  have  to  recompute  the  similarity  between  every  pair  of  their 
jobs,  which  is  a  combinatorial  problem.  Thus,  it  pays  to  store  the  matrix,  and 
just  search  if  for  minima. 

However,  WARD1,  and  WARD2  can  used  the  stored  data  approach,  because 
they  concentrate  on  minimizing  totals  of  job  properties  in  each  cluster  (i.e.,  Ek 
and  Ek/nic).  Anderberg  shows  that  to  evaluate  and  update  these  values  we  need 
only  accumulate  the  following  sums: 

7i*  -  the  total  number  of  jobs  in  cluster  k, 

T*  -  the  sum  of  the  job  values  for  variable  i  in  cluster  k,  and 

Sk  -  the  sum  of  the  squares  of  the  job  values  over  all  variables  in  cluster  k. 

Accumulating  these  values  repeatedly  from  the  original  data  involves  pri¬ 
marily  simple  addition,  and  can  easily  be  tolerated  to  avoid  storing  a  large  simi¬ 
larity  matrix.  The  drawback  of  having  to  recompute  similarities  is  slightly  offset 
by  the  fact  that  we  do  not  have  to  update  the  values  in  a  similarity  matrix.  In 
addition,  as  before,  we  can  save  on  re  computations  and  search  time  by  main¬ 
taining  a  vector  of  previously  calculated  minima.  This  results  again  in  an  order 
Nz  implementation. 

For  the  KMEANS  partition  method,  the  steps  are: 

1)  Define  k  initial  seeds,  i.e.,  k  clusters  of  one  job  each 

2)  For  each  job  in  turn,  compute  its  similarity  to  each  seed 

3)  Assign  the  job  to  the  nearest  seed 

4)  Compute  the  new  seed  value  (variable  means  for  the  cluster), 

except  during  the  final  pass  through  the  data 

5)  Repeat  steps  2)  through  4)  for  all  jobs  in  the  data 

6)  Repeat  step  5)  (go  through  all  the  jobs  again)  until  no  jobs  are  reas¬ 
signed. 

Ignoring  step  1)  for  now,  this  is  easily  the  cheapest  and  fastest  method  so 
far.  In  terms  of  rim  time,  each  pass  through  the  data  is  only  order  N.  In  terms 
of  main  memory,  for  each  cluster  our  main  requirement  is  to  store  the  total 
number  of  jobs,  and  the  sum  of  the  job  values  for  each  variable.  Adding  a  job  to 
a  cluster  involves  incrementing  both  these  quantities.  Dividing  these  two  quanti¬ 
ties  gives  us  the  updated  cluster  mean  (seed)  values.  We  do  not  even  need  to 
store  the  whole  data  set  in  main  memory:  the  jobs  can  be  read  sequentially  from 
auxiliary  memory.  In  this  case,  the  dominant  memory  requirement  will  be  the 
cluster  membership  list  of  the  jobs  (order  N\  see  Note  3  of  Table  2). 

Unfortunately  step  1)  may  be  a  potential  problem.  Some  possible  tech¬ 
niques  for  defining  initial  cluster  seeds  will  be  tested  in  Section  7. 
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TABLE  3 


STORAGE  REQUIREMENTS 
FOR  SIMILARITY  MATRICES 


NUMBER  OF  JOBS 

WORDS  0? 

STORAGE  REQUIRED 

N 

N(N-l)/2 

50 

1225 

100 

4,950 

150 

11,175 

200 

19,900 

250 

31,125 

300 

44,850 

350 

61,075 

400 

79,800 

450 

101,025 

500 

124,750 

600 

179,700 
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For  the  SVD  method,  the  steps  are: 

1)  Compute  principal  components  (eigenvectors)  for  the  data 

2)  Compute  principal  component  scores  for  each  job 

3)  Sort  the  jobs  according  to  the  signs  of  their  component  scores. 

The  technique  used  for  step  l),  singular  value  decomposition,  is  order  Np 2 
(e.g.,  see  [LINP79,  Chapter  1 1],  [WILK71,  p.  134-151]).  Because  p  (the  number  of 
workload  variables)  is  usually  much  smaller  than  N,  this  is  essentially  order  N. 
Step  2)  involves  matrix  multiplication  (order  Np2),  and  step  3)  can  be  done  in 
order  NlogN.  The  overall  result  is  an  extremely  fast  run  time  (see  Table  4),  as 
long  as  p  is  small  (e.g.,  less  than  20). 

In  terms  of  memory  requirements,  the  main  step  is  step  1).  Also  needed 
are  arrays  to  store  and  sort  the  principal  component  scores  by  sign  for  the  N 
jobs.  The  total  requirement  is  basically  order  Np. 

The  above  results  are  summarized  in  Tables  2  and  4.  Order  counts  are 
based  on  the  assumption  that  p  and  k  are  much  less  than  N.  For  the  basic  main 
memory  requirements  of  the  hierarchical  methods,  11*N  and  12 *N  words  must 
be  added,  for  the  stored  matrix  and  stored  data  methods,  respectively.  This  is 
the  minimum  storage  required  to  keep  track  of  the  agglomerative  process  in  the 
programs  from  [ANDE73],  and  hence  to  permit  hand-generation  of  dendograms, 
and  the  examination  of  clusters  at  any  agglomerative  stage.  However,  we  have 
not  explicitly  included  the  process  of  actually  printing  a  dendogram.  A  typical 
routine  from  [ANDE74,  Appendix  G],  which  prints  a  simplified  dendogram, 
required  negligible  CPU  time  (see  Table  4),  and  required  up  to  approximately 
20*AT  extra  words  of  memory  (see  Note  2  in  Table  2). 

Many  useful  conclusions  can  be  drawn  from  these  tables.  In  terms  of  main 
memory,  KMEANS  requires  very  little,  and  WARD1,  WARD2,  and  SVD  require 
slightly  more.  However,  SI  and  CL  quickly  become  very  expensive. 

In  terms  of  run  time,  SVD  and  KMEANS  are  the  fastest  methods,  being  basi¬ 
cally  order  A'  (because  p.k  «N).  The  other  four  methods  (agglomerative)  are  all 
order  N2.  The  run  time  of  KMEANS  will  depend  slightly  on  the  number  of  data 
passes  required,  but  it  is  still  the  fastest  method. 

In  summary  so  far,  we  have  gained  some  idea  of  the  pros  and  cons  of 
different  clustering  approaches.  We  have  seen  that  methods  using  the  stored 
matrix  approach  (SL,  CL)  have  serious  memory  drawbacks.  Agglomerative 
methods  that  can  use  the  stored  data  approach  (WARDl,  WARD2)  have  no  such 
problems,  but  require  more  run  time.  However,  .422  minutes  (25.32  seconds)  of 
CPU  time  to  cluster  631  jobs  is  not  really  long  enough  to  be  considered  a  prob¬ 
lem.  The  potential  speed  and  economy  of  a  simple  partition  method  (KMEANS) 
has  been  indicated.  It  seems  that  if  a  good  set  of  initial  seeds  can  be  found  then 
KMEANS  is  very  attractive.  One  intriguing  possibility  is  to  run  one  of  the  other 
methods  first,  perhaps  on  a  small  representative  job  sample,  and  then  fine  tune 
the  resulting  clusters  using  KMEANS.  This  possibility  will  be  investigated  further 
in  Section  7.  Finally,  we  have  seen  how  a  radically  different  approach  (SVD)  can 
vastly  improve  on  the  run  time  of  traditional  hierarchical  methods,  while  avoid¬ 
ing  the  initialization  problems  of  partition  methods.  However,  the  most  impor¬ 
tant  step  in  our  investigation  remains.  We  must  examine  the  actual  workload 
classes  generated  by  each  method,  to  see  if  they  give  any  useful  insight  into  the 
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TABLE  4 

TYPICAL 

CPU  TIME  REQUIREMENTS 

METHOD 

NUMBER  OF  JOBS  CLUSTERED 

CPU 

TIME  (minutes) 

SVD 

631 

.024 

KMEANS 

(4  seeds, 

2  data  passes) 

631 

.013 

(+  approximately 
.001  for  each 
extra  data 
pass) 

WARD1, 

WARD2 

631 

.422 

(.424  with 
print§d 
dendogram) 

WARD1, 

WARD2 

22  7 

.063 

(.066  with 
printed 
dendogram) 

SL, 

CL 

22? 

.038 

(.040  with 
printed 
dendogram) 

SVD 

227 

.013 

-52- 


workload. 


7.  Comparison  of  Generated  Clusters 

This  section  is  divided  into  subsections,  essentially  one  for  each  method. 
For  the  hierarchical  methods,  it  is  infeasible  to  present  the  details  of  all  AT  — 1 
clustering  stages.  Our  attention  will  focus  on  small  numbers  of  clusters  (e.g.,  3- 
7)  as  being  of  most  interest,  as  well  as  being  convenient  for  presentation  pur¬ 
poses.  These  should  be  sufficient  to  reveal  the  basic  characteristics  and  avail¬ 
able  workload  insight  associated  with  each  algorithm’s  clusters.  The  clusters 
will  be  described  in  three  main  ways:  by  their  means  for  the  seven  workload  vari¬ 
ables  used,  by  their  job  count  breakdown  by  classes  A,  B,  and  W,  and  by  their 
trace  function  values. 


7.1  WARD1 

We  begin  with  WARD1,  and  first  examine  the  stage  with  three  clusters,  for 
comparison  with  classes  A,  B,  and  W  (Table  5).  At  first  glance,  it  seems  that  the 
basic  relative  characteristics  of  the  classes  are  preserved  (clusters  1,  2,  and  3 
approximately  correspond  to  classes  A,  B,  and  W,  respectively).  The  clusters 
generally  represent  a  progression  (in  cluster  order  3-1-2)  from  short  small  jobs 
with  no  steps  or  tapes,  through  medium-sized  jobs  with  some  steps  but  no  tapes, 
to  long  jobs  with  tape  mounts,  many  output  lines,  and  a  few  minutes  in  the  sys¬ 
tem.  Class  W  is  left  totally  intact,  as  we  would  expect,  knowing  its  narrowly- 
defined  limits.  The  larger  jobs  of  clusters  1  and  2  are  basically  distinguished 
from  each  other  by  tape  usage,  followed  by  unit  record  I/O,  elapsed  time  and 
IOWAIT  time.  The  discriminating  power  of  tape  usage  is  seen  (as  in  [AGRA77]); 
cluster  1  contains  only  one  job  with  a  tape  mount,  and  the  other  thirteen  jobs 
that  mounted  tapes  are  together  in  cluster  2.  This  resembles  the  installation’s 
use  of  tape  usage  to  define  class  B  jobs.  Also,  given  that  we  know  these  workload 
variables  are  very  positively  skewed,  we  expect  one  very  large  cluster  of  small 
jobs.  This  is  exactly  what  we  get. 

However,  there  are  also  some  significant  differences  from  the  installation 
class  structure.  There  is  much  overlap  of  classes;  well  over  half  of  the  class  A 
jobs  are  clustered  with  class  W,  because  their  resource  requirements  are  so 
small  that  they  essentially  match  the  mean  class  W  characteristics.  In  fact, 
there  is  a  surprisingly  large  percentage  (88.6%)  of  very  small,  very  similar  jobs 
in  cluster  3.  This  is  perhaps  because  the  period  monitored  was  a  busy  weekday 
afternoon  near  the  end  of  the  term;  many  student  computer  assignments  were 
due,  and  many  students  were  probably  running  the  same  jobs  repeatedly  during 
the  debugging  process.  Also,  there  are  three  class  B  jobs  that  do  not  use  tapes, 
and  they  seem  to  resemble  may  of  the  larger  jobs  of  class  A  (cluster  1). 

To  obtain  more  insight  into  the  workload,  we  looked  at  a  finer 
classification.  The  trace  function  suggested  that  six  clusters  would  be  a  reason¬ 
able  choice  (Table  6),  being  a  point  of  diminishing  returns  in  the  improvement  of 
the  function  as  the  number  of  clusters  increases.  The  small  function  value 
(.272)  indicates  job  clusters  that  are  fairly  homogeneous  and  well-defined  by 
their  means.  The  cluster  of  small  jobs  (cluster  6)  is  still  intact,  which  again 
seems  reasonable.  However,  there  now  seems  to  be  many  useful  subgroups 
among  the  larger  jobs.  Clusters  5  represents  two  jobs  that  seem  to  have  used  a 
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TABLE  5 

COMPARISON  OF  WARD1  CLUSTERS 
WITH  CLASS  A-B-W 


Note i  all  times  are  in  seconds 


ELAPSED 

CPU 

IOWA IT 

JOB 

JOBS 

BY  CLASS 1 

CLUSTER 

TIME 

TIME 

TIME 

CARDS 

LINES 

STEPS 

TAPES 

A 

B 

W 

TOTAL 

1 

170.96 

8.39 

18.09 

630 

1343 

2.4 

.02 

52 

4 

— 

56 

2 

391.21 

8.24 

93.13 

196 

3199 

2.5 

1.1 

3 

13 

- 

16 

3 

9.72 

.94 

1.61 

111 

215 

.1 

0.0 

61 

- 

498 

559 

TRACE 

FUNCTION 

VALUE  1 

.529 

ELAPSED 

CPU 

IOWA IT 

JOB 

JOBS 

BY  CLASS! 

CLASS 

TIME 

TIME 

TIME 

CARDS 

LINES 

STEPS 

TAPES 

A 

B 

W 

TOTAL 

A 

108.75 

4.61 

12.69 

351 

714 

1.7 

0.0 

116 

- 

— 

116 

B 

306.51 

9.03 

23.72 

188 

3435 

2.2 

1.1 

- 

17 

- 

17 

W 

6.91 

.89 

1.46 

114 

212 

0.0 

0.0 

- 

- 

498 

498 

TRACE 

FUNCTION 

VALUE  1 

.633 

TABLE  6 

RESULTS 

OF  WARD1 

6  CLUSTERS 

ELAPSED 

CPU 

IOWA IT 

JOB 

JOBS 

BY  CLASSi 

CLUSTER 

TIME 

TIME 

TIME 

CARDS 

LINES 

STEPS 

TAPES 

A 

B 

W 

TOTAL 

1 

152.16 

6.07 

19.64 

153 

830 

2.6 

0.0 

38 

2 

- 

40 

2 

217.96  14.20 

14.19 

1823 

2628 

2.0 

.06 

14 

2 

- 

16 

3 

147.79 

1.55 

20.94 

25 

593 

1.8 

1.5 

- 

8 

- 

8 

4 

725.38  15.81 

72.16 

487 

1048 

4.0 

•  5 

3 

3 

- 

6 

5 

362.39  : 

L2 .29 

44.75 

4  20075 

1.0 
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stored  program  or  utility  (few  cards)  to  mount  a  tape  and  print  long  reports. 
Jobs  of  clusters  3  and  4  also  use  tapes,  but  print  much  fewer  lines.  Cluster  4 
stands  out  because  it  contains  multi-step  jobs  that  involve  a  great  deal  of  CPU 
and  I/O  activity.  The  rest  of  the  large  jobs  do  not  have  much  tape  usage,  and 
are  divided  in  clusters  1  and  2  mainly  according  to  unit  record  activity. 

This  type  of  information  provides  valuable  input  to  the  workload  analyst. 
The  clusters  identify  basic  types  of  user  applications,  as  well  as  the  workload 
variables  that  distinguish  them.  These  are  classes  of  resource  usage  that  must 
be  represented  in  any  general-purpose  benchmark.  They  must  also  be  con¬ 
sidered  when  planning  how  to  charge  jobs  for  each  resource,  considering  the 
need  for  (and  effect  of)  configuration  changes,  and  introducing  new  services. 
Large  jobs,  such  as  in  clusters  4  and  5,  may  even  need  to  be  carefully  monitored, 
to  anticipate  performance  bottlenecks.  Overall,  the  clusters  produced  by 
WARDl  seem  to  be  very  useful  and  reasonable,  given  our  knowledge  of  the  work¬ 
load. 


7.2  WAKD2 

It  was  mentioned  in  Section  5  that  WAJRD2  might  permit  the  generation  of 
clusters  with  larger  internal  variation,  because  they  contained  many  jobs.  This 
can  result  in  a  tendency  for  small  natural  groups  of  jobs  to  merge  into  larger 
clusters.  In  this  case,  an  intrinsic  property  of  the  algorithm  would  seem  to  be 
imposing  a  poor  structure  on  the  clusters  it  finds.  In  workload  data,  which  is 
typically  very  positively  skewed,  the  above  tendecy  appears  to  be  strong. 

As  the  agglomerative  process  developed,  WARD2  aggregated  most  of  the 
jobs  (about  800)  into  one  large  cluster  (about  580  jobs),  and  one  smaller  cluster 
(about  20  jobs),  leaving  approximately  30  remaining  large  jobs  in  clusters  of  one 
or  two  jobs  each.  The  last  30  stages  then  basically  involved  merging  these  latter 
clusters  one  by  one  with  the  single  very  big  cluster.  The  trace  function  values 
for  3-7  clusters  were  all  greater  than  .6,  indicating  little  gain  from  clustering  the 
jobs  at  all. 

This  type  of  result  is  of  limited  use  to  a  workload  analyst.  The  algorithm 
has  trouble  defining  a  meaningful  class  breakdown;  jobs  tend  to  be  either  all 
lumped  together,  or  stranded  on  their  own.  The  only  possible  use  of  this  would 
seem  to  be  in  the  identification  of  the  single-job  and  double-job  clusters  as 
outliers,  indicating  users  that  may  deserve  special  consideration.  Their  large 
resource  usage  may  indicate  inefficient  programming  style  or  ignorance  of 
installation  principles  of  operation.  Perhaps  they  might  be  advised  to  run  large 
jobs  at  non-peak  hours,  in  the  same  way  that  system  maintenance  programs  are 
run  late  at  night.  Alternatively,  these  jobs  may  require  the  stablishment  of  spe¬ 
cial  services  or  charging  schedules  if  they  are  frequent  enough  and  large 
enough.  Also,  if  cluster  analysis  is  being  used  to  help  define  general  bench¬ 
marks,  these  outliers  may  suggest  a  group  of  users  who  should  be  included,  but 
were  not  captured  very  well  in  the  particular  workload  used. 


7.3  SVD 

This  method’s  main  attractive  feature  is  its  speed.  However,  the  number 
of  clusters  it  can  produce  is  usually  limited  to  a  power  of  2;  at  each  stage  in  the 
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hierarchical  process,  the  addition  of  a  new  principal  component  generally 
causes  each  cluster  to  split  in  two  (positive-scoring  and  negative-scoring  jobs). 
A  more  serious  problem  with  this  method  is  its  basic  assumption  that  jobs  can 
be  meaningfully  divided  into  two  groups  merely  according  to  the  sign  of  their 
scores  on  a  component.  It  does  not  seem  reasonable  to  ignore  the  magnitude  of 
the  scores  (e.g.,  scores  of  .001  and  -.001  are  not  very  different).  This  algorithm 
will  split  a  group  of  related  jobs  that  straddle  the  zero  value  of  a  principal  com¬ 
ponent.  Conversely,  a  group  of  jobs  that  have  the  same  sign  will  be  left  together, 
when  perhaps  they  should  be  subdivided  (e.g.,  because  their  scores  differ 
greatly  in  magnitude). 

Table  7  gives  some  results  obtained  using  SVD.  Four  clusters  are  used, 
because  they  serve  to  demonstrate  the  problems  with  the  technique  and  also 
because  the  trace  function  indicates  that  relatively  little  was  gained  by  doubling 
the  number  of  clusters  to  eight  (an  average  function  improvement  of  only  .032 
per  extra  cluster).  Looking  at  the  cluster  means,  it  is  easy  to  see  the  usefulness 
of  the  first  division,  which  separates  clusters  1  and  2  from  clusters  3  and  4.  The 
jobs  of  the  latter  two  clusters  have  markedly  larger  means  over  all  measures  of 
resource  usage  (except  for  cards  read).  However,  the  problem  discussed  above 
becomes  evident  at  the  second  stage  (partitioning  the  jobs  on  their  scores  for 
the  second  component).  Perhaps  clusters  3  and  4  are  different  enough  in  tape 
and  unit  record  values  to  be  separated,  but  there  is  little  reason  for  a  workload 
analyst  to  bother  to  differentiate  between  clusters  1  and  2.  The  fact  that  com¬ 
pact  job  groups  are  split  up,  and  diverse  ones  seem  to  be  left  intact,  is  shown  in 
the  relatively  high  trace  function  values  (compared  to  WARDl).  Especially 
interesting  is  the  division  of  class  W.  This  does  not  seem  reasonable  at  this  early 
stage,  given  that  we  know  the  restricted  range  of  resources  that  these  jobs  use 
and  how  similar  they  must  therefore  be.  The  only  solution  to  this  type  of  prob¬ 
lem  is  to  examine  the  clusters  after  they  are  produced,  and  possibly  recombine 
any  pairs  of  clusters  that  seem  to  have  been  inappropriately  divided.  However, 
this  means  essentially  undoing  what  the  algorithm  has  done,  which  does  not 
seem  like  a  very  efficient  approach. 

Nevertheless,  there  are  also  some  familiar  results.  Much  of  class  A  is  con¬ 
sidered  essentially  similar  to  class  W  for  these  variables,  and  tape  and  unit 
record  usage  seem  to  be  very  important  discriminators  of  clusters  of  jobs  (clus¬ 
ters  3  and  4). 

7.4  KMEANS 

As  previously  described  in  Section  6,  MacQueen’s  partition  method  is 
potentially  very  fast  and  cheap.  However,  there  are  two  potential  problems:  the 
initial  choice  of  the  number  and  values  of  cluster  seeds,  and  the  potentially 
large  number  of  data  passes  required  for  convergence. 

Anderberg  lists  some  suggestions  for  the  first  problem  [ANDE73,  Chapter 
7],  but  most  of  them  are  subjective  or  heuristic  in  nature.  A  more  attractive 
possibility  is  to  use  the  results  of  a  non-partition  method  for  seeds.  This  possi¬ 
bility  has  been  suggested  in  [D0M075,  ANDE73]  and  elsewhere.  Even  the  results 
of  such  a  method  on  a  small  sample  of  the  jobs  would  probably  be  more  accurate 
than  arbitrarily  choosing  cluster  seeds,  as  MacQueen  originally  suggested.  In 
this  way,  KMEANS  can  be  used  to  improve  upon  a  set  of  clusters  to  produce  even 
more  compact  and  homogeneous  workload  classes.  We  report  below  the  results 
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TABLE  7 

RESULTS  OF  SVD 
4  CLUSTERS 
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ELAPSED 
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1 
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1.37 
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0.0 

14 

- 
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2 
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61 
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0.0 

23 

- 
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3 
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2.15 
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3 
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0.5 
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of  using  KMEANS  on  three  sets  of  cluster  seeds:  a  '’good”  set  from  WARDl,  a 
"poor"  set  from  SVD,  and  the  installation  class  A-B-W  means. 

Regarding  the  second  problem  above,  very  few  data  passes  were  typically 
found  necessary  to  achieve  complete  convergence  (no  reassigned  jobs  between 
successive  data  passes).  This  will  be  shown  in  the  tables  provided:  five  passes  at 
most  were  required. 

When  KMEANS  was  run  on  the  six  WARD1  cluster  means  from  Table  6,  three 
of  the  clusters  were  unchanged  (3,  4,  and  5),  and  the  means  of  the  others  were 
altered  only  negligibly.  The  clusters  from  WARDl  were  so  tightly-defined  about 
their  means  that  only  7  out  of  631  jobs  were  reassigned,  with  trivial  effects. 
Again  almost  half  of  a  class  A  was  merged  with  class  W,  class  W  was  left  intact, 
and  the  whole  range  of  distinct  clusters  created  out  of  the  larger  jobs  was 
preserved.  In  fact,  Table  8  shows  that  for  a  good  initial  cluster  set,  KMEANS  may 
actually  degrade  the  trace  function  value!  This  is  because  KMEANS  is  itself  not  a 
perfect  cluster  optimization  tool;  it  depends  somewhat  on  the  sequential  order 
of  the  jobs  in  the  data.  A  true  optimization  method  would  have  to  consider  every 
possible  way  of  partitioning  the  jobs  into  clusters,  which  is  clearly  impossible. 
All  in  all,  there  appears  to  be  little  reason  to  use  KMEANS  after  WARDl. 

The  story  is  different  if  KMEANS  is  given  a  poor  initial  result,  such  as  the  4- 
cluster  scheme  from  SVD.  After  five  passes,  KMEANS  drastically  rearranges  the 
jobs  among  the  clusters,  and  dramatically  improves  the  trace  function  value, 
until  it  is  almost  as  good  as  that  of  WARDl  (see  Table  9a).  Although  SVD  pro¬ 
duces  job  groups  with  undesirable  properties,  KMEANS  seems  able  to  modify 
them  to  yield  a  reasonable  class  structure.  The  small  combined  run  time  and 
memory  costs  of  the  two  methods  make  their  combination  a  possible  second 
alternative  to  WARDl.  Again  we  have  the  familiar  trends  in  the  cluster  means. 
The  only  new  result  is  that  an  even  higher  proportion  of  class  A  now  merges  with 
class  W  in  cluster  4  (e.g.,  compared  to  the  results  of  Tables  5  and  6),  raising  the 
mean  cluster  values  slightly,  but  still  resulting  in  a  well-defined  cluster  of  rela¬ 
tively  short,  small  jobs.  We  conclude  that  KMEANS  can  be  very  useful  for  improv¬ 
ing  on  a  poor  initial  method. 

When  KMEANS  is  applied  to  the  means  of  classes  A,  B,  and  W,  again  the  jobs 
are  drastically  rearranged.  Class  characteristics  somewhat  similar  to  those 
seen  in  the  three  clusters  of  WARDl  are  produced,  after  four  passes  (Table  9b), 
in  that  class  W  and  most  of  class  A  form  an  overwhelmingly  large  cluster  of  short 
jobs  with  small  mean  values  of  resource  usage.  The  larger  jobs  are  split  into  two 
clusters:  one  uses  tapes  but  little  unit  record  I/O  or  CPU  time,  and  the  other 
uses  few  tapes  but  a  great  deal  of  unit  record  I/O  and  much  more  CPU  time. 
Cluster  1  indicates  that  there  are  many  small  general  purpose  jobs  that  are  in 
class  B  only  because  of  their  tape  usage.  Otherwise  they  are  fairly  similar  to  the 
larger  jobs  of  class  A.  In  short,  the  installation-defined  classes  do  not  seem  to 
describe  the  natural  job  groups  in  a  totally  accurate  manner,  at  least  for  the 
given  workload  and  resource  variables  used.  Because  they  are  defined  for 
administrative  and  economic  purposes,  we  would  not  expect  them  to  be  the  best 
classification  for  jobs  on  a  pure  resource  usage  basis. 


7.5  Verification  of  Workload  Sample 

In  order  to  extend  our  comparison  to  include  SLand  CL,  which  have  order 
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N2  growth  in  memory  requirements,  a  smaller  but  representative  sample  of  our 
631  jobs  was  drawn,  using  stratified  sampling  techniques  [C0CH53,  Chapter  5]. 
Details  of  the  process  are  in  [CHU79,  Chapter  10],  and  the  resulting  sample 
characteristics  are  presented  in  Table  10.  The  sample  consisted  of  227  jobs, 
including  all  the  class  A  and  B  jobs  from  the  original  workload.  Relative  percen¬ 
tage  differences  from  the  original  population  values  are  in  parentheses. 

We  present  the  results  of  running  WARDl  (our  best  method  so  far)  on  the 
sample  in  order  to  establish  two  points.  First  we  wish  to  see  if  the  sample  is 
representative  enough  to  reproduce  the  clusters  obtained  by  running  WARDl  on 
the  whole  population  (631  jobs).  Hopefully  our  sample  will  generate  the  same 
basic  job  groups,  with  large  savings  in  run  time.  Second,  we  wish  to  provide  a 
standard  against  which  to  compare  SL  and  CL,  which  can  only  be  run  economi¬ 
cally  on  smaller  job  populations. 

Briefly,  the  results  were  very  good;  again,  six  clusters  seemed  to  be  an 
acceptably  set  of  clusters  (see  the  trace  function  values  in  Table  12).  Because 
most  of  these  clusters  contained  only  class  A  and  B  jobs,  and  because  our  sam¬ 
ple  retained  all  of  these  two  classes,  these  clusters  were  exactly  reproduced. 
For  the  big  cluster  that  typically  contained  all  of  class  W  and  much  of  class  A, 
the  reduction  in  the  number  of  class  W  jobs  used  in  the  sample  caused  a  slight 
increase  in  the  mean  values  of  resource  usage  (see  Table  11).  However,  the 
differences  are  acceptably  small;  this  is  still  a  well-defined  cluster  of  very  short, 
small  jobs,  with  relatively  low  values  of  resource  usage.  Referring  to  Table  4  we 
see  that  a  significant  reduction  in  CPU  time  was  obtained,  which  was  approxi¬ 
mately  proportional  to  the  square  of  the  reduction  in  N. 

As  a  further  demonstration  of  the  sample’s  goodness,  both  sets  of  clusters 
means  (WARDl  on  227  jobs  and  WARDl  on  631  jobs)  were  used  as  seeds  for  a 
KMEANS  run  on  all  631  jobs.  Significantly,  both  sets  of  seeds  produced  identical 
clusters  at  complete  convergence  (after  two  passes).  Similar  results  were 
obtained  using  four  clusters  from  SVD,  instead  of  six  clusters  from  WARDl.  Thus 
we  felt  confident  in  using  this  sample  to  evaluate  SL  and  CL  against  WARDl. 

7.6  SL  and  CL 

Table  12  gives  the  trace  function  values  for  the  clusters  resulting  from 
WARDl,  SL,  and  CL  on  our  job  sample.  These  values  can  be  compared  with  each 
other,  but  not  with  those  resulting  from  clustering  the  whole  population, 
because  the  function  denominator  is  different.  As  shown  in  the  table,  neither  of 
the  new  methods  performed  as  well  as  WARDl.  For  each  given  number  of  clus¬ 
ters,  the  higher  values  for  SL  and  CL  indicate  that  some  of  their  clusters  contain 
very  disssimilar  jobs  and  hence  do  not  represent  homogeneous  groups  of  jobs. 
Cluster  means  are  therefore  not  presented,  because  the  relatively  large  varia¬ 
tion  of  values  within  each  cluster  makes  them  less  meaningful. 

The  motivation  behind  SL  is  that,  for  each  cluster,  every  job  should  be 
more  similar  to  some  other  job  in  the  same  cluster  than  to  any  job  outside  the 
cluster.  Unfortunately,  this  means  that  two  clusters  with  two  largely  different 
means  may  be  merged  if  they  merely  have  one  pair  of  similar  jobs  between 
them.  This  undesirable  result  often  occurs  in  workload  data;  if  enough  jobs  are 
used,  they  will  represent  a  fairly  continuous  range  of  values  over  each  workload 
variable.  Thus,  even  between  very  distinct  groups  of  jobs  there  will  generally  be 
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TABLE  10 

SAMPLE  CHARACTERISTICS 
TOTAL  SAMPLE*  22 7  JOBS 
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TABLE  11 

COMPARISON  OF  WARDl  CLUSTERS 
FROM  22 7  JOBS  vs.  63I  JOBS 

CLUSTERS  1-5*  IDENTICAL 

CLUSTER  6* 
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a  few  Intermediate  jobs  that  cause  the  groups  to  merge.  This  phenomenon  is 
often  referred  to  as  "chaining".  The  results  are  somewhat  similar  to  WARD2; 
basically  one  large  cluster  containing  almost  all  the  jobs,  and  then  a  multitude 
of  outliers  in  clusters  of  one  or  two  jobs.  It  seems,  therefore,  that  SL  has 
difficulty  in  resolving  relatively  distinct  job  groups  in  workload  data. 

CL  produces  slightly  better  trace  function  values  than  SL,  but  shares  a 
major  weakness  with  it;  it  can  be  affected  by  a  single  pair  of  jobs.  In  this  case,  if 
two  clusters  have  very  close  means  and  seem  generally  to  contain  very  similar 
jobs,  they  may  still  not  be  merged,  if  there  is  one  pair  of  jobs  between  them  that 
are  sufficiently  dissimilar. 

Unfortunately,  these  two  methods  are  generally  quite  popular.  Our  investi¬ 
gation  seems  to  show  that  the  information  they  provide  for  the  workload  analyst 
is  not  very  useful,  and  perhaps  even  deceptive.  Therefore,  these  methods  are 
not  recommended  for  workload  characterization. 


8.  Conclusions 

In  this  paper,  we  have  demonstrated  the  intrinsic  differences  between,  and 
results  of,  some  simple  clustering  algorithms,  using  computer  workload  data. 
Although  many  other  methods  were  not  included,  the  workload  analyst  should 
now  have  a  basic  idea  of  how  cluster  analysis  works  and  what  different  methods 
can  give  him,  in  terms  of  useful  knowledge  about  the  components  of  his  work¬ 
load. 


We  have  considered  only  some  simple  algorithms.  It  may  be  that  other 
methods,  or  modifications  to  these  ones,  may  produce  even  better  results  [e.g., 
see  ANDE73,  EVER74,  C0RM71]. 

Although  we  did  not  intend  to  choose  a  "best"  method,  WARD1  seems  to 
have  emerged  as  the  most  generally  useful  method,  according  to  our  criteria, 
for  clustering  workload  data.  None  of  the  other  hierarchical  methods  gives  as 
much  useful  information,  and  KMEANS  requires  an  initial  choice  of  clusters.  In 
addition,  SL  and  CL  are  only  convenient  for  small  samples.  The  many  outliers 
contained  in  workload  data  are  less  of  a  problem  for  a  hierarchical  method, 
because  they  can  be  treated  as  separate  clusters  during  the  process. 

Still,  the  best  and  safest  approach  is  to  run  more  than  one  method  on  the 
data.  For  example,  besides  WARDl,  the  analyst  might  also  run  an  SVD-KMEANS 
combination,  or  merely  run  SVD  on  its  own,  using  a  large  number  of  com¬ 
ponents,  and  recombine  the  resulting  clusters  as  he  sees  fit.  Then  the  analyst 
can  choose  to  use  only  those  clusters  produced  by  all  or  the  majority  of  the 
methods. 

Obviously,  a  workload  analyst  who  can  identify  not  only  the  overall  charac¬ 
teristics  of  his  workload,  but  also  the  basic  components  within  it,  is  well- 
equipped  both  to  tailor  the  system  services  to  meet  user  needs  and  to  advise 
users  on  how  to  use  the  system  efficiently.  He  also  has  a  better  chance  of 
modelling  his  workload  accurately  for  purposes  of  system  modelling  and  predic¬ 
tion  of  future  needs.  Cluster  analysis  has  been  shown  to  be  a  very  useful  and 
objective  tool  for  these  purposes.  However,  the  analyst  must  choose  carefully 
from  the  many  available  methods  and  be  aware  of  their  potential  strengths  and 
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weaknesses.  We  also  have  shown  how  the  resulting  clusters  must  be  interpreted 
and  evaluated  in  the  context  of  the  analyst's  own  knowledge  of  his  workload. 
Cluster  analysis  should  be  regarded  as  a  tool  for  discovery,  intended  to  augment 
the  analyst’s  own  knowledge,  not  to  replace  it. 
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Abstract 

A  number  of  case  studies  involving  the  use  of  queueing  network  models  to  investigate  actual 
computer  systems  are  surveyed.  After  suggesting  a  framework  by  which  case  studies  can  be 
classified,  we  contrast  various  parameter  estimation  methods  for  specifying  model  parameters 
based  on  measurement  data.  A  tabular  summary  indicates  the  relationships  among  nineteen 
case  studies. 


This  paper  has  been  accepted  for  presentation  at  the  Conference  on  Simulation,  Measurement 
and  Modeling  of  Computer  Systems,  Boulder,  Colorado,  August  1979.  The  paper  will  be 
published  in  the  proceedings  of  this  conference. 
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1.  INTRODUCTION 


The  growing  complexity  of  computer  systems  has  motivated  the  development  of  analytic  tools 
to  investigate  computer  system  performance.  Queueing  network  models  are  one  such  tool. 
Simplifying  .ssumptions  permit  complex  systems  to  be  characterized  by  a  small  number  of 
parameters.  Anticipated  or  proposed  changes  to  the  system  can  be  represented  by  adjusting 
some  of  the  parameter  values.  Queueing  network  models  have  proven  effective  in  predicting 
the  effects  of  changes  on  system  performance  for  the  sake  of  configuration  planning. 

Two  types  of  queueing  network  models  are  in  widespread  use:  analytic  models  and  simulation 
models.  The  accuracy  of  analytic  models  and  the  amount  of  detail  of  a  system  they  can 
capture  are  restricted  by  their  computational  solution  algorithms.  However,  since  the  solution 
algorithms  are,  within  their  restrictions,  fairly  general,  one  particular  solver  can  be  applied  to  a 
wide  spectrum  of  models.  Thus,  analytic  models  can  be  designed  an  implemented  very  quickly. 
Also,  some  of  their  solution  algorithms  are  computationally  very  efficient.  Simulation  models 
are  virtually  unlimited  in  the  amount  of  detail  they  can  represent.  However,  their  design  and 
implementation  generally  takes  more  time,  and  their  evaluation  requires  much  more  computa¬ 
tion  than  the  evaluation  of  most  analytic  models.  Thus,  when  a  model  is  to  be  used  for  rough 
performance  estimates,  when  many  parameter  sets  must  be  evaluated,  or  when  the  error  in  the 
parameter  values  is  potentially  large,  it  is  advantageous  to  use  analytic  models.  When  complex 
algorithms  must  be  modeled  accurately,  or  when  or  when  important  features  of  a  model  violate 
the  assumptions  of  the  analytical  solution  algorithms,  simulation  should  be  chosen  to  evaluate 
the  model.  Sometimes,  both  solution  techniques  can  be  combined  in  hybrid  models. 

The  parameter  values  used  in  queueing  network  models  must  be  extracted  from  accounting 
data  and  measurement  data  obtained  from  hardware  and  software  monitors.  Various 
"reasonable"  approaches  to  estimating  the  value  of  a  particular  parameter  yield  widely  varying 
values.  Thus,  the  choice  of  parameter  estimation  method  is  critical.  Inappropriate  choices  can 
lead  to  errors  larger  than  those  resulting  from  simplifying  assumptions  and  omission  of  details. 

Section  2  presents  a  scheme  for  classifying  queueing  network  models.  In  section  3,  we 
examine  various  queueing  network  model  parameters  and  contrast  the  estimation  methods  that 
have  been  used  in  case  studies.  Finally,  we  present  a  tabular  summary  of  case  studies  that 
have  involved  the  use  of  queueing  network  models.  Our  presentation  assumes  familiarity  with 
queueing  network  models  [BCMP75,  DB78]. 


2.  CLASSIFICATION  OF  QUEUEING  MODELS 

In  recent  years  the  range  of  analytically  tractable  queueing  network  models  has  been  broad¬ 
ened  significantly.  Thus,  it  is  useful  to  classify  such  models  According  to  the  degree  to  which 
they  can  explicitly  represent  features  of  computer  systems.  One  possible  classification  method 
is  based  on  a  model  space  described  by  the  following  six  (reasonably  independent)  dimensions: 

model  structure 
arrival  process 
workload  classification 
queueing  disciplines 
service  demand  description 
server  characteristics 
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The  first  three  dimensions  are  global  dimensions  pertaining  to  the  entire  model,  and  the 
remaining  three  describe  individual  service  centers.  Below,  we  discuss  the  dimensions  individu¬ 
ally,  indicating  those  classes  that  have  proven  to  be  most  important  in  the  development  and  the 
application  of  queueing  network  models.  Generally,  in  each  dimension,  the  classes  can  be 
ordered  according  to  complexity,  detail,  and  cost  of  solution. 

The  model  structure  describes  the  number  of  service  centers  and  the  manner  in  which  jobs  flow 
among  them.  We  distinguish  the  following: 

(i)  single  server  model  (possibly  with  a  feedback  loop), 

(ii)  cyclic  queueing  model  (a  constant  number  of  customers  cycle  among  the  service 

centers), 

(iii)  central  server  model  (from  a  designated  service  center,  customers  move  to  other 

centers,  but  after  receiving  service,  they  return  to  the  designated  server), 

(iv)  general  queueing  network  (arbitrary  routing  among  service  centers),  and 

(v)  hierarchical  queueing  network  (a  single  service  center  at  one  level  of  detail  is 

represented  by  a  network  on  a  lower  level  of  detail). 

The  arrival  process  indicates  the  manner  in  which  new  customers  come  into  existence.  A 
model  is  one  of: 

(i)  closed  (fixed  number  of  customers  in  each  routing  chain), 

(ii)  open  (arrivals  and  departures  in  all  routing  chains),  and 

(iii)  mixed  (some  routing  chains  open  and  some  closed). 

The  arrival  rates  in  open  chains  may  be  constant  rate  Poisson,  load-dependent  Poisson,  or 
non-Poisson. 

The  workload  classes  characteristic  indicates  groupings  of  customers  that  are  statistically 
indistinguishable.  Possibilities  are: 

(i)  single  class  model, 

(ii)  multiple  class  model  with  no  class  changes,  and 

(iii)  multiple  class  model  with  class  changes. 

The  queueing  disciplines  we  distinguish  are: 

(i)  station  balance  disciplines  (including  processor  sharing,  preemptive  last-come-first- 

served,  and  no-queueing), 

(ii)  class-independent  work-conserving  disciplines  (including  first-come-first-served), 

and 

(iii)  strict  priority  disciplines  (based  on  customer  class). 

(iv)  general  disciplines 

The  service  demand  description  can  be  specified  as  either 

(i)  a  workload  vector,  in  which  the  mean  total  service  required  by  a  customer  of  a  class 

at  each  device  is  stated,  or 

(ii)  a  routing  matrix  indicating  the  pattern  of  stochastic  movements  of  customers,  and 

the  distribution  of  service  times  for  each  class  at  each  device.  The  service  time 
distribution  may  be  assumed  to  have  a  particular  form  or  to  have  specified 
moments. 

The  server  characteristic  describes  the  reaction  of  the  server  to  the  load.  These  include 
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(i)  load-independent  servers,  and 

(ii)  load  dependent  servers. 

If  the  service  rate  is  load  dependent,  it  may  depend  on  the  number  of  customers  of  the  same 
class  at  the  service  center,  on  the  total  number  of  customers  at  the  service  center,  or  on  the 
total  number  of  customers  in  a  subsystem. 

Having  established  the  six  dimensions  of  classification,  we  can  specify  the  type  of  a  particular 
model  as  a  six  element  classification  vector  in  which  the  first  three  components  place  the  model 
in  the  first  three  dimensions  above,  and  the  remaining  components  specify  the  most  complex 
characteristic  of  any  server  in  the  model  with  respect  to  each  of  the  last  three  dimensions.  For 
example,  the  classification  vector  below  describes  a  particular  model  type: 

central  server  model 
closed 

multiple  class  with  no  class  changes 
station  balance  disciplines 
workload  vectors 
load-independent  servers 


Important  Points  in  the  Model  Space 

In  table  1,  we  show  how  various  model  types  fit  into  the  framework.  It  should  be  kept  in  mind 
that  this  classification  of  model  types  is  just  according  to  abstract  model  properties.  It  does 
not  include  any  practical  aspects  of  their  application  to  computer  systems.  The  solution 
methods  are  not  a  classification  criterion,  although  they  are  mentioned  in  some  cases  in  the 
comments  to  emphasize  the  practical  importance  of  a  particular  model  type. 


3.  MODELING  COMPUTER  SYSTEMS 

Analytic  queueing  network  models  can  be  applied  to  a  wide  range  of  computer  systems.  A 
introduction  to  measuring  and  modeling  computer  systems  of  various  architectures  is  presented 
in  [ROSE78].  A  particular  modeling  technique  must  be  selected  according  to  the  amount  of 
detail  required  in  the  results.  Computer  system  models  with  very  little  detail  [GIAM76a]  as 
well  as  models  with  a  large  amount  of  detail  [CC78,  KRAE78]  have  proven  useful.  Restric¬ 
tions  are  the  cost  of  the  computational  solution  and  the  amount  of  detail  with  which  the  input 
parameters  can  be  confidently  specified. 

The  activities  of  a  system  which  are  to  be  modeled  must  be  selected  according  to  their  impact 
on  the  performance  measures  of  interest.  Only  activities  that  use  resources  heavily  or 
otherwise  strongly  influence  the  system  behavior  should  be  included  in  the  models.  Exception¬ 
al  activities  like  error  handling  and  recovery  or  atypical  load  situations  need  not  be  taken  into 
account. 

In  the  following  sections,  practical  issues  of  the  application  of  queueing  network  models  to 
computer  systems  are  discussed.  In  section  3.1,  performance  monitors  and  some  of  their 
properties  that  are  important  for  their  use  in  modeling  are  discussed  briefly.  In  3.2,  we  discuss 
how  the  various  components  of  computer  systems  have  been  represented  in  queueing  network 
models  in  the  case  studies  reviewed,  and  how  the  parameters  for  queueing  network  models  of 
actual  computer  systems  are  determined.  Section  3.3  contains  some  remarks  on  validation 
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1 

Classification 

Vector  1 

Reference 

1 

Comments 

1 

1 

1 

SS 

OP 

1 

CIWC 

EXP 

LI  1 

[KLEI75] 

1 

birth-death  models,  including 

1 

_  1. 

I 

the  machine  repairman  model 

1 

1 

CYC 

OP 

1 

CIWC 

EXP 

LI  1 

[K0EN58] 

1 

first  cyclic  model 

1 

1 

1 

CYC 

OP 

1 

CIWC 

EXP 

LI  1 

[GS73] 

1 

diffusion  approximation  model 

1 

1 

1 

MV 

1 

CGELE75] 

1 

1 

1 

1 

1 

GN 

OP 

1 

CIWC 

EXP 

LD  1 

CJACK63] 

1 

shows  product  form  solution 

1 

1 

1 

GN 

CL 

1 

CIWC 

EXP 

LI  1 

CGN67] 

1 

closed  model  and  product 
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1 

1 

1 

1 

form  solution 

1 

1 

1 

CSM 

CL 

1 

CIWC 

HYPO  LI  i 

CGAVE67] 

1 

no  queue  lengths  and  marginal 

1 

1 

1 

EXP 

1 

1 

distributions 

1 

1 

1 

CSM 

CL 

1 

CIWC 

EXP 

LO  1 

CBUZE71] 

1 

defines  central  server  model 

1 

1 

1 

[BASK71] 

1 

and  efficient  computational 

1 

1 

1 

1 

1 

algorithm 

I 

1 

1 

GN 

MI 

cc 

SB 

WLV 

LO  1 

CBCMP75] 

1 

theortlcal  basis  of  local 

1 

1 

1 

[W0NG75] 

1 

balance  models  and  efficient 

1 

1 

1 

[CHW75a] 

1 

solution  algorithms 

1 

1 

1 

[RK75] 

1 

1 

1 

1 

CLAM77] 

1 

1 

1 

1 

1 

CCHT77] 

1 

1 

1 

1 

GN 

OP 

cc 

SB 

WLV 

LO  1 

[SM79] 

1 

mean  value  analysis 

1 

1 

1 

CL 

1 

[REIS79] 

1 

1 

1 

1 

HM 

OP 

R 

SB 

WLV 

LO  1 

[CHW75a] 

1 

Norton's  theorem  reduction 

1 

1 

1 

CL 

1 

....  1 

1 

1  - 

1 

1 

1 

GN 

OP 

R 

CIWC 

PTO 

LO  1 

CCHW75b] 

1 

approximations  for  general 

1 

1 

CL 

1 

CSC75] 

1 

service  time  distributions 

1 

1 

1 

[SLTZ77] 

1 

and  CIWC  disciplines  using 

1 

1 

1 

1 

1 

local  balance  techniques 

1 

1 

1 

GN 

OP 

R 

PRIO 

WLV 

LO  1 

[SC75] 

1 

approximations  for  priority 

1 

1 

CL 

1 

[REIS76] 

1 

disciplines  using  local 

1 

1 

1 

1 

[SEVC77] 

1 

balance  techniques 

1 

1 

1 

GN 

OP 

I 

CIWC 

GO 

LI  1 

[K0BA74a] 

1 

diffusion  approximation 

1 

1 

CL 

MV 

1 

[K0BA74b] 

1 

1 

1 

1 

1 

CGP76] 

1 

1 

1 

1 

GN 

OP 

R 

CIWC 

GO 

LI  1 

[GP77] 

1 

multiple  class  diffusion 

1 

1 

1 

CL 

1 

1 

approximation 

1 

1 

1 

GN 

MI 

cc 

GEN 

PTD 

LO  1 

CWR66] 

1 

global  balance  techniques 

1 

1 

1 

[HWC75] 

1 

1 

1 

1 

CLEVY77 ] 

1 

1 

1 

1 

CSTEW78] 

1 

1 

Table  l. 


procedures,  and  in  section  3.4,  we  briefly  describe  some  software  packages  to  support  model¬ 
ing  studies.  Section  3.3  is  a  table  summarizing  the  case  studies  surveyed. 


Measurement  Tools 

There  are  a  number  of  different  types  of  measurement  tools  that  can  be  used  to  supply  data 
for  queueing  network  models. 
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mode  1 

structure 

arrival 

process 

SS 

single  server  model 

OP 

open  model 

CYC 

eye  1 i c  mode  1 

CL 

closed 

CSM 

central  server  model 

HI 

mixed 

GN 

general  network 

HM 

hierarchical  model 

workload  classes 

1 

single  class 

queueing  disciplines 

R 

multiple  classes 

SB 

station  balance 

CC 

class  changes 

CIWC 

c  1  ass- i ndependent 

serv i ce-conserv i ng 

serv i ce 

demand 

PR  1 0 

priori ty 

WLV 

workload  vector 

GEN 

general  d i sc i p 1 i nes 

EXP 

exponential  distribution 

MV 

mean  and  variance 

server 

character i st  i  c 

HYPO 

hypoexponent i a  1  distribution 

LI 

load- i ndependent 

PTD 

phase  type  distribution 

LD 

load-dependent 

GO 

general  distribution 

Abbreviations  of  Table  1 


Hardware  monitors  are  devices  external  to  and  independent  of  the  measured  computer  system. 
Electronic  probes  attached  to  the  computer  can  sense  its  operating  state  and  transmit  the  state 
to  the  hardware  monitor  for  recording.  Hardware  monitors  can  record  the  physical  state  of  a 
computer  system,  such  as,  CPU  busy,  CPU  in  supervisor  state,  channel  busy,  number  of  I/O 
operations  at  a  device.  They  cannot  record  operating  system  related  data,  so  the  data  are  not 
usually  broken  down  by  workload  class. 

Software  monitors  are  data  collection  programs  that  run  in  the  computer  that  is  to  be  measured. 
There  are  several  kinds  of  software  monitors:  Accounting  monitors  log  the  resource  requests  of 
user  tasks  for  accounting  purposes.  They  are  user  task  oriented  monitors.  Resource  requests 
are  not  necessarily  equal  to  resource  consumption,  since  not  all  I/O  requests,  for  example, 
result  in  I/O  operations.  Also,  accounting  monitors  usually  do  not  report  the  overhead  caused 
by  a  job,  so  that  the  accounted  resource  usage  does  not  add  up  to  the  total  resource  usage. 
System-oriented  monitors  record  the  usage  of  the  various  hardware  and  software  resources  of  a 
computer  from  a  system  point  of  view.  Often,  they  also  give  operating  system  related  data  like 
paging  rates  or  multiprogramming  levels.  In  most  monitors,  these  data  are  not  broken  down  by 
workload  class.  There  are  two  major  approaches  monitoring:  event-driven  monitoring  and 
sampling.  In  sampling,  a  task  is  dispatched  periodically  and  collects  information.  In  event- 
driven  monitoring,  the  monitor  is  invoked  at  operating  system  events,  such  as  interrupts,  to 
record  information  pertaining  to  those  events.  Random  sampling  monitors  usually  cause  less 
overhead  than  event-driven  monitors,  but  they  also  give  less  detailed  data. 


3.2  Review  of  Parameter  Estimation  Methods 

The  process  of  modeling  can  be  divided  into  several  phases  and  steps.  Two  important  steps 
are  to  determine  (1)  how  to  represent  the  various  features  of  the  computer  system  that  are  to 
be  modeled,  and  (2)  how  to  specify  the  parameters  for  these  models.  These  two  steps  are 
dependent  on  each  other  since,  for  each  representation  of  a  feature,  the  corresponding 
parameters  must  be  specified.  In  what  follows,  these  two  aspects  of  modeling  are  discussed  by 
surveying  case  studies  using  analytic  models  to  investigate  the  performance  of  actual  computer 
systems. 
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Parameter  Requirements 

The  modeling  assumptions  made  in  virtually  all  case  studies  to  be  reviewed  are  compatible  with 
the  local  balance  assumptions  [BCMP75]  or  satisfy  the  less  stringent  conditions  for  operational 
analysis  [DB78].  Both  sets  of  assumptions  lead  to  the  same  computational  algorithms.  Closed 
models  of  this  type  require  as  input  parameters  only  the  multiprogramming  levc^l  and  the  relative 
utilizations  of  the  servers.  For  multiple  class  models,  these  parameters  must  be  broken  down 
by  class.  Open  models  require  the  arrival  rates  of  the  jobs/transactions  and  their  total  resource 
requirements.  As  a  consequence,  Kobayashi  and  Reiser  [KR75]  and  Giammo  [GIAM76b]  point 
out  that  only  the  total  amount  of  work  brought  to  a  server  by  a  job  is  required  as  input  for 
models  of  this  type.  To  obtain  such  performance  measures  as  utilization,  throughput,  queue 
length  distribution,  and  mean  response  time,  all  dynamic  aspects  of  a  program’s  behavior  (such 
as  routing  probabilities  and  service  burst  length  distributions)  can  be  ignored.  Thus,  if  models 
are  specified  in  terms  of  routing  probabilities  and  mean  service  times,  these  data  must  be 
aggregated  in  order  to  obtain  actual  input  parameters.  This  disaggregation  followed  by  an 
immediate  aggregation  was  done  in  most  of  the  case  studies  we  review  here.  The  apparent 
motive  for  specifying  model  parameters  in  such  detail  is  to  conform  to  the  general  queueing 
network  model  view  of  computer  systems  in  which  jobs  are  visualized  as  flowing  among  service 
centers  governed  by  service  time  distributions  and  routing  probabilities.  With  this  more 
general  view,  a  broader  class  of  models  can  be  investigated. 

There  are  several  ways  of  specifying  a  consistent  set  of  relative  utilizations. 

a)  total  load  during  T:  X(i,r)  =  L(i,r)/R(i) 

b)  load  per  partition:  X(i,r)  =  L(i,r)/(MPL(r)*R(i)) 

c)  load  per  job:  X(i,r)  =  L(i,r)/(C(r)*R(i)) 

d)  load  per  cycle:  X(i,r)  =  L(i,r)/(cycles(r)*R(i)) 

T:  measurement  period 

X(i,r):  relative  utilization  of  server  i  due  to  tasks  of  class  r 

L(i,r):  number  of  operations  executed  by  server  i  for  tasks  of  class  r 

R(i):  service  rate  of  server  i,  assumed  class-independent 

MPL(r):  mean  multiprogramming  level  of  class  r 

C(r):  completions  of  jobs  of  class  r 

cycles(r):  total  number  of  cycles  of  class  r  jobs  through  the  network 

Within  a  model,  the  chosen  definition  must  be  used  consistently.  It  can  be  shown  that  these 
definitions  are  mathematically  equivalent  [KR75,  GIAM76b],  and  that  they  can  be  calculated 
from  the  same  measurement  data.  So  one  should  chose  the  method  for  which  the  parameters 
can  be  calculated  most  easily. 

In  early  models,  the  distribution  of  CPU  service  bursts  was  determined  from  event  traces  of 
the  modeled  systems  [MOOR71,  BOYS71].  Two  different  burst  definitions  used  were  the  time 
between  successive  I/O  requests,  called  a  logical  burst,  and  the  time  a  task  spends  at  the  CPU 
without  interruption,  called  a  physical  burst.  The  distribution  of  the  physical  CPU  bursts  was 
reported  to  be  exponential  due  to  the  last-come-first-served-preemptive-resume  discipline, 
whereas  the  distribution  of  the  logical  bursts  was  hyperexponential  [MOOR71].  By  varying 
the  number  of  bursts  and  the  burst  lengths,  it  was  realized  that  the  definition  used  did  not 
affect  the  results  of  the  model  very  much  as  long  as  the  total  amount  of  work  for  the  servers 
did  not  change.  Similarly,  the  second  moment  of  the  distribution  scarcely  affected  the  results 
of  the  models  [BOYS71].  These  findings  are  compatible  with  the  theoretical  derivations  in 
[BCMP75,  KR75],  that  for  a  wide  class  of  assumptions  only  the  total  workload  brought  to  a 
server  affects  the  model  results. 
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For  models  not  satisfying  local  balance  or  the  operational  analysis  assumptions,  usually  the 
first  two  moments  of  the  probability  distributions  of  the  service  times  must  be  specified 
[CHW75b,  SC75,  SLTZ77].  In  these  cases,  the  results  may  be  sensitive  to  how  the  service 
bursts  are  defined.  Whichever  burst  definition  is  adopted,  it  is  very  difficult  to  measure  burst 
distributions,  since  the  monitors  that  are  required  to  perform  these  measurements  perturb  the 
system  significantly  on  most  computer  architectures.  Regardless  of  how  the  parameter 
estimation  was  done,  none  of  the  reviewed  case  studies  that  model  actual  computer  systems 
involves  models  not  satisfying  local  balance  or  the  conditions  for  operational  analysis. 


Number  of  Workload  Classes 

The  number  of  workload  classes  to  be  distinguished  in  queueing  network  models  is  an  impor¬ 
tant  parameter.  One  restriction  on  this  number  is  the  computational  feasibility,  since  the 
amounts  of  computation  and  storage  required  to  solve  a  model  rise  sharply  with  the  number  of 
classes.  Another  restriction  is  the  breakdown  of  resource  requirements  into  workloads 
provided  by  the  monitors.  System  monitors  usually  report  the  total  usage  of  the  important 
system  components  fairly  accurately.  Data  from  accounting  monitors  and  knowledge  of  the 
usage  pattern  of  these  components  by  the  workload  classes  must  be  used  to  break  the  total 
resource  usage  down  by  workload  classes. 

The  first  important  class  distinction  in  models  is  the  distinction  between  batch  and  interactive 
work  [ROSE76,  SU78].  In  general,  models  should  distinguish  among  workloads  with  signifi¬ 
cantly  differing  resource  and  performance  requirements  [WB76,  BARD78].  To  keep  the 
complexity  of  the  model  manageable,  only  workload  classes  that  contribute  significantly  to  the 
system  workload  or  otherwise  strongly  influence  the  system’s  behavior  should  be  modeled. 
However,  where  possible,  the  model  should  use  the  same  classes  as  the  operating  system  in 
order  to  give  performance  predictions  in  terms  of  the  classes  specified  by  the  computer 
system’s  management  [BUZE78,  CC78].  Going  even  further,  the  concept  of  class  changes  can 
be  used  to  distinguish  among  various  phases  of  a  job’s  execution,  such  as  execution  in  supervi¬ 
sor  or  in  problem  state  [KRAE78],  or  a  job’s  invocation  of  system  tasks  [KGT77].  Also,  the 
system  overhead  can  be  represented  by  adding  an  extra  workload  class  whose  resource 
requirements  consist  of  the  system  overhead  [BUZE78].  If  just  one  class  of  the  workload  is  of 
interest,  a  single  class  model  can  be  applied  by  reducing  the  capacities  of  the  servers  by  the 
system  overhead  and  the  resource  consumption  of  the  other  workload  classes  [BOYS71]. 


CPU  Service  Requirements 

It  should  be  noted  that  the  CPU  service  time  of  a  job  is  actually  a  consequence  of  two 
quantities:  the  service  demand  by  the  programs  and  the  server  capacity  (or  the  CPU  speed). 
Few  authors  make  this  distinction  [DG75,  KR75,  REIS76]. 


a)  Single  Class  Models 

In  single  class  models,  the  CPU  time  per  task  can  be  calculated  by  dividing  the  total  CPU  time 
by  the  number  of  tasks  processed.  In  most  of  the  reviewed  case  studies,  however,  the 
following  formula  is  used  for  deriving  the  mean  time  of  a  CPU  service  burst: 

U  *  T 
M  - - 
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where  U  is  the  CPU  utilization,  T  is  the  measurement  period,  and  IO  is  the  total  number  of 
CPU  bursts,  usually  assumed  to  be  equal  to  the  total  number  of  I/O  requests.  This  method 
corresponds  to  case  d)  of  the  above  formulas.  Giammo  [GIAM76a]  uses  case  a),  the  total 
busy  times  recorded  by  the  monitor,  as  the  relative  utilizations  for  his  models. 

In  single  class  models,  the  overhead  is  usually  not  a  very  important  issue.  The  above  formula, 
and  the  equivalent  formulas,  automatically  include  the  CPU  overhead  and  distribute  it  equally 
among  the  jobs.  If  one  assumes  that  the  CPU  overhead  is  a  function  of  a  parameter  explicitly 
represented  in  the  model,  the  overhead  can  easily  be  included  in  the  model  by  increasing  the 
CPU  service  requirements  according  to  that  function.  The  CPU  overhead  may,  for  example, 
be  made  dependent  on  the  multiprogramming  level  or  the  paging  rate  [BW74,  WB76]. 
However,  it  seems  to  be  very  difficult  to  obtain  the  measurements  to  quantify  these  functions. 

The  above  remarks  all  assume  that  the  CPU  is  represented  by  one  server  in  the  model. 
However,  if  there  are  several  dedicated  processors,  or  if  different  states  of  the  CPU  are  to  be 
represented,  a  CPU  submodel  can  be  established  whose  results  are  then  used  to  specify  the 
characteristics  of  a  single  CPU-server  in  the  overall  model  [BCBKTD75]. 


b)  Multiple  Class  Models 

The  basic  formula  presented  in  the  previous  section  can  easily  be  modified  to  apply  for 
multiple  class  models: 

A(i) 

M(i)  =  — . 

I0(i) 

where  M(i)  is  the  mean  CPU  burst  time  of  class  i,  A(i)  is  the  total  accounted  CPU  time  of 
class  i,  and  IO(i)  is  the  total  number  of  I/O  operations  accounted  for  class  i. 

A  difficult  problem  with  multiple  class  models  is  the  allocation  of  CPU  overhead.  Overhead  in 
this  context  is  not  necessarily  defined  as  all  the  operating  system  activity.  It  is  rather  defined 
as  resource  usage  that  is  not  accounted  to  the  workload  classes.  The  overhead  is  the  sum  of 
all  accounted  resource  usage  subtracted  from  the  total  resource  usage  reported  by  system 
oriented  monitors.  Since  most  accounting  monitors  do  not  attribute  all  CPU  time  to  user 
classes,  the  cause  of  the  remaining  overhead  must  be  determined.  Rose  [ROSE76]  suggested 
applying  the  following  formula  to  calculate  the  mean  CPU  service  times  of  class  i,  implicitly 
distributing  the  CPU  overhead: 

U  *  T  *  f  ( i ) 

M(i) . — 

I0(i) 

where  U  is  the  total  CPU  utilization,  T  is  the  measurement  period,  f(i)  is  the  relative  fraction 
for  the  CPU  time  of  class  i,  and  IO(i)  is  the  number  of  I/O  requests  of  class  i.  For  the 
determination  of  IO(i),  the  problem  of  the  distribution  of  overhead  I/O  operations  arises,  as 
normally  not  all  I/O  requests  are  recorded  by  accounting  monitors.  To  determine  f(i),  one  can 
use  the  relative  fraction  of  the  number  of  customers  active  at  a  time  [ROSE76].  This  would 
spread  all  the  CPU  time  equitably  among  the  classes,  leaving  no  class  distinction  in  the  CPU 
service  requirements,  which  is  certainly  not  a  very  realistic  assumption.  Another  proposal  is  to 
use  the  relative  fraction  of  the  accounted  CPU  time  of  the  classes  [SU78].  This  assumes  that 
the  unaccounted  CPU  time  is  proportional  to  the  accounted  CPU  time.  In  the  ideal  case,  the 
amount  of  CPU  overhead  caused  by  the  various  system  services  would  be  known.  For  a  first 


approximation,  one  can  distribute  the  unaccounted  CPU  time  among  the  workload  classes 
according  to  the  number  of  I/O  requests  or  other  system  activities  that  are  known  to  cause 
CPU  overhead.  It  has  been  shown  that  misallocations  of  overhead  may  strongly  influence  the 
results  of  the  models  [KS79], 

Once  the  unaccounted  CPU  time  caused  by  each  workload  class  is  determined,  it  may  be 
distributed  among  the  classes  [ROSE76,  KS79],  it  may  be  aggregated  in  a  special  overhead 
class  [BUZE78],  or  the  CPU  service  rate  may  be  reduced  accordingly  [LC77]. 


Memory 

Memory  enters  the  modeling  considerations  in  two  aspects:  the  memory  access  time  and  the 
memory  space  as  a  resource. 

The  memory  access  time  partly  determines  the  CPU  capacity.  Usually  it  need  not  be  measured, 
but  it  is  given  for  a  CPU-memory  configuration.  If  a  cache  is  used,  however,  the  cache  hit 
ratio  must  be  measured  to  determine  the  average  memory  access  time.  Memory  access  time 
and  cache  hit  ratio  may  explicitly  be  represented  in  models  [BCBKTD75,  KS79]. 

The  memory  space  as  a  resource  is  difficult  to  represent  explicitly  in  queueing  network  models 
since  jobs  must  hold  the  CPU  and  memory  at  the  same  time  to  receive  service  from  the  CPU. 
The  class  of  queueing  network  models  discussed,  however,  requires  the  assumption  that  a  job 
holds  only  one  resource  at  a  time. 

In  most  case  studies  reporting  on  models  of  systems  that  have  only  the  concept  of  real  memory 
space,  the  memory  size  limits  of  the  system  are  reflected  in  the  models  by  limiting  the  multi¬ 
programming  level.  Since  the  multiprogramming  level  is  usually  determined  by  other  parame¬ 
ters,  the  memory  constraints  are  modeled  implicitly.  In  [NEIL76,  BBC77],  the  multiprogram¬ 
ming  level  is  determined  using  the  distributions  of  the  memory  requirements  of  the  tasks.  In 
models  of  interactive  systems,  the  memory  constraints  lead  to  the  necessity  of  swapping 
programs  in  and  out  of  the  memory.  The  swap  I/O  operations  can  be  represented  in  the 
models  as  a  regular  portion  of  an  interaction.  The  swapping  probabilities  can  be  determined  as 
a  function  of  the  active  multiprogramming  level  and  the  storage  size  [CHEN75].  The  memory 
size  allocated  to  a  task  and  the  number  of  swaps  a  task  experiences  are  usually  reported  by 
accounting  monitors. 

When  modeling  virtual  memory  systems,  the  paging  1/ O  must  be  taken  into  account  as  well.  In 
this  case,  using  routing  probabilities  and  mean  service  times  to  calculate  the  relative  utilization 
of  the  I/O  servers  is  not  advisable,  since  for  every  page  fault  rate  the  corresponding  routing 
probabilities  must  be  calculated  by  solving  a  system  of  linear  equations.  Just  adding  the 
number  of  paging  I/O  operations  to  the  file  I/O  operations,  as  can  be  done  when  using  case  c) 
of  the  above  equations,  is  much  simpler.  The  page  fault  rates  depend  on  the  page  reference 
behavior  of  the  programs  and  on  the  real  memory  available.  Predicting  the  page  fault  rates  for 
multiprogramming  mixes  and  storage  sizes  other  than  in  measured  system  is  a  very  difficult 
problem,  since  the  information  required  is  not  usually  recorded  by  monitors.  Also,  the  data 
required  to  build  page  life-time  functions,  the  most  popular  form  of  expressing  page  reference 
behavior,  can  only  be  recorded  incurring  considerable  overhead,  thus  distorting  the  measure¬ 
ment.  Buzen  gives  formulas  for  a  synthetic  life-time  function  and  shows  how  to  use  them  to 
calculate  the  parameters  for  a  central  server  model  [BUZE71].  In  [WB76],  a  theoretical  model 
for  virtual  memory  is  developed.  In  the  vicinity  of  the  measured  point,  the  life-time  functions 
are  approximated  by  a  linear  function.  The  paging  disk  is  modeled  by  a  load-dependent  server. 
The  CPU  overhead  for  paging  in  the  model  is  determined  using  a  linear  function  of  the  page 
fault  rate.  In  [DG75],  it  is  shown  how  page  fault  rates  for  various  memory  management 
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policies  can  be  calculated  from  the  page  life-time  curves  of  the  programs.  In  [CC78],  a 
renewal  model  based  on  distributions  of  the  pages  inter-reference  times  is  employed  to 
calculate  the  paging  rates  for  the  different  multiprogramming  levels  and  locality  properties  of 
the  programs.  Using  this  renewal  model  that  is  described  in  [CC77],  the  page  fault  rates  under 
varying  memory  sizes  can  be  predicted  using  measured  information  on  the  page  reference 
behavior  of  programs.  The  distributions  of  the  unreferenced  intervals  can  be  recorded  with 
much  less  overhead  than  the  data  required  to  build  page  life-time  functions.  In  [BARD77],  the 
multiprogramming  level  is  determined  so  that  the  working  sets  of  the  active  programs  fit  into 
the  memory.  Most  monitors  for  virtual  memory  systems  report  paging  related  data  such  as 
number  of  pages  transferred  or  paging  rates,  some  even  report  the  working  set  size.  Page 
life-time  functions,  however,  have  not  been  measured,  but  only  have  been  estimated  in  the 
case  studies  reviewed. 


Number  of  I/O  Operations  and  Routing  Probabilities 

In  cyclic  queueing  models,  only  the  completion  probabilities  (i.e.,  the  probabilities  that  a  job 
leaves  the  system  at  the  end  of  a  cycle)  must  be  specified.  The  number  of  cycles  is  set  as  the 
total  number  of  I/O  operations.  Since  usually  this  probability  is  assumed  to  be  independent  of 
the  number  of  cycles  a  job  has  already  completed,  it  is  implied  that  the  number  of  times  a  job 
cycles  through  the  system  is  geometrically  distributed.  In  [BOYS71],  this  assumption  is 
confirmed  by  measurements. 

For  models  using  several  servers  to  represent  the  I/O  subsystem,  the  total  number  of  I/O 
operations  broken  down  by  channels  or  devices  must  be  known.  These  data  are  reported  by 
most  system-oriented  monitors.  (Accounting  monitors  usually  record  only  user  requests  for 
I/O  operations.)  The  relative  frequencies  of  I/O  operations  to  the  various  I/O  devices  can  be 
used  as  routing  probabilities  [MOOR71,  BW74,  ROSE76,  SU78].  If  case  c)  of  the  above 
formulas  is  used,  the  number  of  I/O  operations  per  task  is  multiplied  by  the  mean  service  time 
of  an  I/O  operation  to  obtain  the  I/O  time  per  task.  In  single  class  models,  this  method 
automatically  allocates  all  recorded  I/O  operations  and  does  not  require  special  considerations 
for  overhead  I/O  operations.  If  paging  or  swapping  is  modeled,  the  routing  probabilities  must 
reflect  the  I/O  requests  resulting  from  these  activities  as  well  [BUZE71,  DG75].  In  [WB76], 
the  explicit  calculation  of  the  routing  probabilities  is  avoided  by  deriving  the  relative  utiliza¬ 
tions  of  the  paging  servers  directly  from  measured  system  variables. 

In  multiple  class  models,  the  problem  of  overhead  I/O  operations  that  cannot  easily  be 
allocated  to  workload  classes  arises.  The  total  number  of  I/O  operations  may  be  allocated 
among  the  classes  according  to  the  ratios  of  the  accounted  I/O  requests  [ROSE76,  SU78]. 
This  reflects  the  assumption  that  the  job  classes  cause  I/O  operations  in  proportion  to  then- 
accounted  I/O  requests.  At  least  some  of  the  unaccounted  I/O  operations  can  be  allocated 
among  the  workload  classes  according  to  accounted  I/O  activities  like  page  faults,  swaps,  data 
sets  used,  spooling  data,  etc.  [KIEN77,  BUZE78].  Once  the  number  of  I/O  operations  per 
workload  class  are  determined,  the  class-dependent  routing  probabilities  can  be  calculated  as 
the  relative  frequencies  of  I/O  operations  to  devices  within  the  classes. 

Often,  a  loop  around  the  CPU  with  the  completion  probability  of  a  task  as  its  routing  proba¬ 
bility  is  used  to  determine  the  system  throughput.  The  system  throughput  can  also  be  calculat¬ 
ed  using  the  utilization  of  any  server  as  evaluated  by  the  queuing  network  model: 


U  (i) 

THR(i)  - - - 

WDM  (i) 
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where  THR(i)  is  the  throughput  of  class  i  jobs  at  the  server,  U(i)  is  the  utilization  of  the 
server  by  class  i  jobs,  and  WDM(i)  is  the  work  demand  of  class  i  jobs  on  the  server.  This 
approach  gives  essentially  the  same  results  as  the  approach  using  the  completion  loop,  but  the 
network  topology  is  simpler. 


I/O  Service  Times 

To  determine  an  appropriate  representation  of  the  I/O  subsystem  in  a  queueing  network  model 
is  a  difficult  task.  The  activities  of  the  major  components  of  the  subsystem,  the  channels  and 
the  devices,  are  partially  overlapped,  and  the  modeling  techniques  used  cannot  accurately 
represent  overlapped  activities.  Also,  the  I/O  activities  are  difficult  to  measure.  There  has 
been  a  good  deal  of  discussion  of  how  to  model  the  channel-disk  subsystem.  The  major 
problems  are  (1)  how  to  represent  the  parallelism  between  the  channel  and  the  disk,  (2)  how 
to  represent  the  overall  service  time  of  an  I/O  operation,  and  (3)  how  to  represent  the 
queueing  structure  of  the  operating  system  that  usually  has  a  queue  for  each  disk  and  a 
separate  queue  for  the  channel.  Usually,  one  of  these  aspects  is  emphasized  at  the  expense  of 
the  others.  The  modeling  approaches  found  were  the  following: 

disks  only  [BW74,  CHEN75,  WB76], 

channel  only  [GIAM76b,  ROSE76], 

channel  and  disks  coalesced  into  one  device  [CDW75,  PRIC76,  CC78,  SU78], 

channels  and  disks  separately  [DIET77,  LC77,  KS79], 

separate  I/O  submodel  [BCBKTD75,  BARD77,  KRAE78J. 

’Disks  only’  should  be  modeled  when  the  utilization  of  the  disks  is  a  required  model  result. 
The  ’channels  only’  approach  can  be  used,  when  the  channel  is  busy  during  the  entire  I/O 
operation,  as  for  example  on  selector  channels.  The  channel  and  the  connected  disks  can  be 
modeled  as  one  server,  when  the  time  that  the  disks  are  busy  but  not  the  channels  is  very 
short,  so  that  this  extra  time  does  not  result  in  an  unrealistically  high  channel  contention. 
Measurements  of  disks  where  the  channel  is  connected  to  the  disk  during  the  rotational  delay  - 
IBM  2314  type  disks  -have  shown  that  the  seek  time  is  less  significant  than  the  rotational 
delay  [PRICE76].  Thus,  collapsing  the  channel  and  the  disks  into  one  server  seems  to  be 
justified  for  this  type  of  disk.  The  results  of  the  model  support  this  view.  Modeling  overlap¬ 
ped  seeks  did  not  improve  the  model  in  Price’s  study  significantly.  Since  the  seek  and  the  wait 
for  the  channel  may  be  performed  in  parallel,  and  since  seeks  for  different  requests  may  be 
done  in  parallel,  coalesced  channel-disk  representation  can  give  accurate  answers  only  for 
lightly  loaded  systems,  where  the  amount  of  parallelism  within  the  disk  subsystem  is  small.  In 
[BCBKTD75,  DIET77,  LC77,  KS79],  both  channels  and  devices  -  disks  where  the  channel  is 
disconnected  during  the  rotational  delay,  like  on  the  IBM  3330  type  disks  -are  represented  in 
the  models.  The  case  studies  agree  that  the  time  of  an  I/O  operation  during  which  channel 
and  disk  operations  are  overlapped  should  be  modeled  as  being  spent  at  the  channel  to 
correctly  model  the  bottleneck  of  the  channel.  The  remaining  time  of  the  I/O  operation 
during  which  only  the  disk  is  busy  is  modeled  as  being  spent  at  the  disk.  The  separation  of  the 
channel  and  the  disks  is  required  since  on  a  3330  type  disk  the  channel  is  connected  during  a 
smaller  portion  of  the  I/O  operation  than  on  a  2314  type  disk.  A  separate  I/O  submodel  can 
be  chosen  when  more  detail  is  to  be  modeled,  or  in  order  to  decompose  the  model  for  easier 
evaluation. 

Whichever  way  the  I/O  subsystem  is  represented,  the  mean  service  times  (subsequently  just 
called  service  times)  of  each  of  the  servers  in  the  model  must  be  determined.  If  the  total 
number  of  I/O  operations  per  workload  class  is  known,  the  total  server  busy  time  per  work¬ 
load  class  (or  per  task  in  a  workload  class)  can  be  calculated  by  multiplying  the  number  of  the 
1/ O  operations  per  class  by  the  mean  service  time. 
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The  formula  most  frequently  used  to  derive  the  mean  I/O  service  times  is  similar  to  the 
formula  shown  for  mean  CPU  service  times: 

U  ( i )  *  T 

M(i)  = 

I0(i) 

where  M(i)  is  the  mean  service  time  of  server  i,  U(i)  is  its  utilization,  IO(i)  is  the  total  number 
of  I/O  requests  to  this  server,  where  server  may  be  the  channel,  the  device,  or  both,  and  T  is 
the  measurement  period.  The  mean  service  times  of  channels  and  disks  are  usually  assumed  to 
be  class-independent.  An  alternate  approach  is  to  derive  them  from  device  busy  times,  service 
rates,  and  block  sizes  [MOOR71,  BW74,  SU78].  For  coalesced  channel-disk  representation, 
these  approaches  may  be  combined  by  calculating  the  channel  transfer  time  using  the  above 
formula  and  then  adding  the  mean  seek  time.  If  disks  and  channels  are  modeled  separately, 
care  must  be  taken  to  model  the  overall  time  of  an  I/O  operation  correctly.  The  channel 
service  time  is  determined  according  to  the  above  formula.  The  disk  service  time  is  determined 
similarly,  but  then  the  channel  service  time  is  subtracted  to  obtain  an  accurate  total  time  of  an 
I/O  operation.  To  include  additional  rotations  after  reconnect  misses  on  disks  with  rotational 
position  sensing  (RPS),  the  I/O  service  times  can  be  determined  iteratively  by  calculating  the 
probability  for  RPS  misses  from  the  channel  utilization  and  assuming  a  geometric  distribution 
of  the  number  of  misses  per  I/O  operation  [ZAH076,  WXLH77,  KRAE78].  The  I/O  service 
times  should  be  calculated  for  each  server  separately.  They  may  vary  among  devices,  even  for 
the  same  type,  since  they  depend  on  the  pattern  of  usage.  For  example,  disks  used  with 
sequential  access  methods  probably  have  smaller  seek  times  than  disks  used  with  random 
access. 

In  [BCBKTD75,  BARD77,  KRAE78],  special  models  are  used  for  the  I/O  subsystems.  These 
submodels  are  represented  in  the  overall  models  by  one  aggregate  I/O  server  that  has  load- 
dependent  service  rates. 


Multiprogramming  Level 

There  are  many  different  methods  for  the  determination  of  the  multiprogramming  level.  Some 
system-oriented  monitors,  as,  for  example,  the  RMF  monitor  for  the  MVS  operating  system, 
take  periodic  samples  of  the  multiprogramming  level  in  the  system  and  report  the  average 
[IBM77].  The  MPL  can  also  be  determined  from  accounting  data.  If,  for  example,  the 
resident  times  of  the  jobs  are  known,  the  following  formula  may  be  used  to  obtain  the  average 
MPL: 


resident  times 

MPL  - - - - 

T 

where  MPL  is  the  multiprogramming  level  and  T  is  the  measurement  period. 

If  the  multiprogramming  level  is  fairly  stable  during  a  measurement  experiment,  which  is, 
.except  for  the  end-effects,  often  true  in  benchmark  experiments,  the  number  of  partitions  or 
initiators  may  be  used  as  the  multiprogramming  level  [BW74,  ROSE76].  Another  method  is  to 
use  the  internal  queue  lengths  as  reported  by  software  monitors  [SU78].  One  must,  however, 
be  aware  that  some  of  the  available  monitors  may  not  display  all  the  relevant  queues  and  not 
all  tasks  displayed  may  be  user  tasks.  In  hierarchical  queueing  network  models,  the  specifica¬ 
tion  of  multiprogramming  levels  can  be  avoided  altogether.  From  the  number  of  completed 
jobs  and  the  measurement  interval  length,  an  average  arrival  rate  is  calculated.  This  rate  is 
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then  used  as  the  arrival  rate  of  jobs  in  the  user  interface  model.  The  network  model  on  the 
operating  system  level  is  evaluated  for  all  possible  multiprogramming  mixes.  The  resulting 
throughput  rates  are  used  as  load-dependent  service  rates  in  the  user  interface  model  [KSS77]. 

In  general,  the  measured  or  derived  average  multiprogramming  level  will  not  be  integer  as 
required  by  the  solution  methods  of  most  models.  The  models  can  be  evaluated  using  the  next 
higher  and  the  next  lower  integer  multiprogramming  levels,  and  the  results  can  be  linearly 
interpolated  [ROSE76].  This  procedure  can  also  be  applied  with  multiple  class  models  using 
multidimensional  interpolation.  When  interpolating,  one  should  try  to  find  out  whether  the 
functions  are  approximately  linear  in  the  area  of  interpolation.  If  the  functions  are  linear,  the 
order  in  which  the  dimensions  are  interpolated  does  not  affect  the  results. 


Operating  System  Algorithms 

The  queueing  disciplines  permitted  by  the  local  balance  assumptions  [BCMP75,  CHT77]  are 
not  very  representative  of  the  algorithms  generally  found  in  operating  systems  of  computers. 
So  there  have  been  many  approaches  to  represent  more  accurately  the  fashion  in  which  the 
hardware  components  that  are  usually  modeled  are  used  by  the  software. 

Since  most  operating  systems  employ  priority  disciplines  in  one  form  or  another,  and  since  their 
behavior  is  fundamentally  different  from  the  local  balance  disciplines,  it  is  necessary  to 
represent  them  in  the  models.  One  way  to  do  this  is  to  reduce  a  network  using  Norton’s 
theorem  reduction.  The  resulting  model  has  two  servers,  one  that  uses  a  priority  discipline, 
and  another  that  represents  the  remainder  of  the  network.  One  workload  class  in  this  reduced 
model  contains  the  workload  whose  performance  is  to  be  investigated,  the  other  two  classes 
contain  the  workloads  that  have  higher  and  lower  priority  respectively.  This  two-server 
three-class  network  is  solved  by  a  global  balance  technique  [SC75].  If  only  two  priorities  are 
involved  in  a  preemptive  priority  discipline,  the  server  with  the  priority  discipline  may  be  split 
up  into  two  servers.  One  server,  serving  the  high  priority  workload,  has  the  full  capacity.  The 
other  server,  serving  the  low  priority  workload,  has  the  fraction  of  the  capacity  that  is  not  used 
by  the  high  priority  workload  on  the  first  server  [REIS76,  SEVC77].  Since  the  two  workloads 
interact  on  the  other  servers  of  the  network,  the  capacity  of  the  low  priority  server  must  be 
determined  iteratively.  This  scheme  can  conceivably  be  used  for  more  than  two  priority  classes 
as  well.  In  [BARD79],  this  method  is  generalized  to  handle  non-preemptive  priorities  with  the 
mean  value  analysis.  It  is  assumed  that  a  task  receives  service  proportional  to  its  priority.  The 
processing  capacity  is  dedicated  to  the  workloads  not  in  equal  shares  as  in  the  processor 
sharing  discipline,  but  in  proportions  based  on  their  priorities.  This  scheme  also  allows  the 
implementation  of  the  "fair  share"  scheduling  discipline  [BARD77]. 

Blocking  of  resources  due  to  limited  queue  sizes  and  overlapped  resource  usage  by  tasks  are 
further  problems  that  occur  in  operating  systems  and  that  are  not  straightforward  to  model. 
Approximations  of  these  effect  can  be  achieved  in  models  using  the  mean  value  analysis.  By 
imposing  restrictions  or  relaxations  respectively  on  the  numbers  of  jobs  that  are  considered  to 
contribute  to  the  time  a  task  takes  to  pass  a  queue,  reasonably  accurate  results  may  be 
obtained  [BARD79].  In  [LAM77]  local  balance  models  with  constraints  on  the  population  size 
are  treated  theoretically. 

In  addition  to  internal  delays  in  a  computer  system,  jobs  can  also  incur  external  delays.  A 
resource  may  not  be  available  because,  for  example,  a  removable  storage  volume  is  not 
mounted.  The  effect  of  volume  mounting  can  be  modeled  by  a  set-up  server  representing  the 
human  operator  in  the  model  [BW74,  GIAM76a].  It  is  difficult  to  determine  a  queueing 
discipline  and  a  service  rate  for  such  a  server  [GIAM76a]. 
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In  most  models,  communications  subsystems  and  spooling  systems  are  not  represented.  The  I/O 
devices  controlled  by  these  systems  are  active  at  the  start  and  at  the  end  of  jobs/transactions. 
They  do  not  really  contribute  to  the  internal  delay.  The  consumption  of  internal  resources  by 
these  subsystems  is  usually  included  in  the  system  workload  as  overhead  [BUZE78,  KS79]. 
However,  the  devices  they  control  may  significantly  contribute  to  the  response  time  a  user 
perceives.  This  is  not  the  same  time  as  the  internal  response  time  that  is  usually  calculated  in 
models.  The  communications  subsystem  and  the  spooling  system  may  be  modeled  using  a 
hierarchical  model.  The  internal  throughput  and  response  times,  calculated  in  a  first  queueing 
network  model  on  the  operating  system  level,  are  used  as  parameters  in  a  second  model  on  the 
user  interface  level.  If  this  second  model  is  a  spooling  model,  it  is  a  linear  model  with  three 
servers,  the  card  reader,  the  internal  model,  and  the  line  printer.  If  it  is  a  telecommunications 
model,  it  contains  two  servers,  the  internal  model  and  the  telecommunications  controller  that  is 
used  for  the  input  as  well  as  for  the  output. 

Often,  not  only  isolated  features  of  operating  systems  must  be  represented  in  models,  but 
entire  operating  system  concepts  must  be  captured.  In  [BUZE78],  the  OS/VS2  MVS  operating 
system  for  IBM  /370  computers  is  modeled  in  a  fair  amount  of  detail.  The  model  covers  the 
interactive  swapping,  the  demand  paging,  the  dispatching  priorities,  and  the  concepts  of 
domains  and  performance  groups.  In  [KRAE78],  the  modeling  effort  is  focused  on  the 
supervisor  of  the  DOS/ VS  operating  system  for  IBM  /370  computers.  The  entire  I/O  portion 
of  the  system  is  modeled  by  one  server  whose  characteristics  are  determined  by  a  submodel. 
The  CPU  has  five  queues  for  the  various  supervisor  activities  that  are  distinguished  by  their 
priorities.  The  model  is  sufficiently  detailed  to  take  instruction  path  lengths  of  supervisor 
routines  as  inputs.  It  is  used  to  evaluate  alternative  operating  system  designs. 

If  more  operating  system  detail  is  to  be  modeled,  one  must  resort  to  hybrid  methods.  An 
introduction  to  hybrid  modeling  is  presented  in  [SCHW78].  A  hybrid  model  of  OS/VS2  MVS 
is  described  in  [CC78].  The  activities  on  the  level  of  the  dispatcher  and  lower  that  occur  with 
high  frequency  are  modeled  with  an  analytic  model.  The  activities  that  occur  with  lower 
frequencies  are  modeled  using  a  simulation  model  that  explicitly  represents  the  complex 
algorithms  of  the  scheduler  and  load  controller  SRM  [IBM76].  This  way,  complex  algorithms 
can  be  represented  in  the  model  very  accurately. 


3.3  Validation  and  Prediction 

Before  a  model  is  used  to  predict  a  system’s  performance  under  conjectured  changes  of  the 
system  or  its  workload,  the  validity  of  the  model  must  be  established.  It  must  be  determined 
whether  (1)  the  assumptions  about  the  system’s  properties  and  (2)  the  decisions  how  to 
implement  them  are  justified.  And  it  must  be  determined  whether  (3)  the  parameter  values  of 
the  model,  often  estimated  rather  than  measured,  are  good  estimates  of  the  real  parameters. 
Generally,  these  three  aspects  of  the  validation  cannot  be  separated  since  one  can,  for 
example,  offset  unrealistic  implementation  of  system  features  by  adjusting  the  parameter  values 
appropriately  [BCBKTD75]. 

There  are  several  ways  to  account  for  uncertainties  in  the  parameter  estimation.  In 
[MOOR71],  upper  and  lower  bounds  of  the  parameters  are  established,  and  envelope  curves  of 
the  performance  measures  are  calculated.  In  [LC77],  a  parametric  study  is  performed  to 
determine  the  sensitivity  of  the  model.  Then  the  most  crucial  parameters  are  estimated 
particularly  carefully.  If  there  are  data  from  a  number  of  measurement  and  modeling  experi¬ 
ments  available,  statistical  analysis  can  be  applied  to  the  measurements  and  modeling  results  to 
establish  confidence  limits  [GIAM76a]. 
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To  determine  which  components  of  a  computer  system  should  be  represented  in  a  model,  a 
number  of  model  configurations  may  be  evaluated,  and  their  results  compared  with  the 
performance  of  the  actual  computer  system.  This  has  been  done  in  particular  to  find  an 
appropriate  representation  of  the  disk/channel  subsystem,  where  the  overlap  between  the 
channel  and  the  disks  is  difficult  to  model  [CDW75,  CHEN75,  PRIC76,  DIET77]. 

Since  the  "correct"  representation  of  a  priority  discipline  is  not  possible  in  local  balance 
models,  various  approximations  to  the  discipline  may  be  implemented  to  calculate  upper  and 
lower  bounds  on  the  performance  measures  [SEVC77].  This  is  a  way  of  validating  modeling 
decisions.  Some  studies  rather  go  the  opposite  way.  They  assume  that  their  representation  of 
the  computer  system  in  the  model  is  appropriate,  and  that  the  input  parameter  values  must  be 
adjusted  (calibrated)  until  the  model  results  correspond  to  the  measured  performance  [BW74, 
ROSE76].  This  method  should  only  be  used  if  the  adjustment  procedure  itself  can  be  validat¬ 
ed  by  independent  experiments. 

Validation  can  be  performed  against  performance  measure  values  obtained  in  a  number  of 
ways.  If  one  is  confident  about  what  the  important  features  of  a  system  are  but  wants  to 
validate  their  representation  in  the  model,  or  if  the  modeled  system  is  only  in  a  planning  state, 
the  analytic  model  may  be  validated  against  simulation  models  [KRAE78,  BARD79],  One  can, 
however,  have  more  confidence  in  a  model,  if  it  has  been  validated  against  measured  values 
from  a  real  system.  These  measurements  may  be  made  during  production  operation  of  the 
system  [CDW75,  GIAM76a,  BARD78,  BUZE78,  LC77,  SU78].  This  has  the  advantage  that 
the  model’s  validity  is  established  for  an  actual  production  workload  which  is  typically  the 
workload  to  be  investigated.  If  the  measurements  for  the  validation  are  made  during  bench¬ 
mark  experiments  [CDW75,  ROSE76,  WB76,  DIET77,  CC78,  KS79],  the  experiment  is  more 
easily  controlled  and  repeatable.  Thus  one  can  change  the  configuration  of  the  system  or  the 
workload  and  validate  the  predictive  ability  of  the  model  [CDW75,  DIET77,  CC78].  Howev¬ 
er,  it  is  not  easy  to  determine  whether  a  benchmark  workload  represents  the  production 
workload  of  a  modeled  system  sufficiently  well  to  establish  the  validity  of  the  model  for  the 
production  workload. 


3.4  Modeling  Systems 

In  modeling  studies,  the  techniques  for  measuring  and  estimating  the  parameters  for  the  models 
are  as  important  as  the  techniques  for  model  evaluation.  A  general  guideline  for  the  process  of 
modeling  has  been  described  in  [KS79].  Below,  we  briefly  describe  software  packages 
designed  to  support  various  stages  of  the  modeling  process. 

As  described  in  [KGT77],  an  event-drive  monitor  supplied  by  a  manufacturer  has  been 
modified  to  record  all  the  data  required  by  the  model.  A  special  reduction  routine  calculates 
the  model  parameters  that  are  then  fed  into  the  solution  package.  The  data  reduction  pro¬ 
grams  as  well  as  the  definition  of  the  model  for  the  solution  program  are  tailored  to  a  specific 
system,  a  UNIVAC  1108  running  the  EXEC8  operating  system. 

A  similar  procedure  is  described  in  [BARD78].  The  system  is  measured  by  a  special  monitor 
whose  output  is  processed  by  a  reduction  program  to  produce  the  model  parameters.  This  can 
be  done  on  the  modeled  system.  The  model  solver  is  available  on  a  network  system.  The 
model  is  specified  in  an  interactive  dialog,  solved  by  a  computer  at  a  central  site,  and  the 
results  are  shipped  back  to  the  terminal.  Since  the  model  is  for  one  operating  system  only 
(VM  /370),  many  assumptions  can  be  embedded  in  the  modeling  system.  In  order  to  evaluate 
the  performance  of  a  workload  on  various  system  configurations,  the  modeling  system  can 
adapt  the  workload  specification  to  a  spectrum  of  configurations.  The  modeler  is  guided  by 
the  system  through  a  dialog,  so  that  he  need  not  be  an  expert  on  queueing  network  models. 
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As  described  in  [CC78],  a  comprehensive  monitor  was  built  to  obtain  highly  detailed  data  on 
the  computer  and  its  operating  system  (OS/VS2  MVS).  These  data  were  then  subjected  to 
extensive  statistical  analysis  to  determine  data  interrelationships  [CF78].  A  smaller  set  of  data 
was  used  as  input  for  the  hybrid  model. 

These  modeling  systems  are  all  tailored  towards  particular  computer  systems  and  particular 
operating  systems.  In  general,  the  model  design  and  the  parameter  estimation  must  be 
performed  individually  for  each  model  and  cannot  be  automated.  Only  the  numerical  solution 
packages  can  be  used  as  a  common  tool  for  a  wide  spectrum  of  models.  A  number  of  such 
packages  have  been  developed  [KELL73,  REIS76,  BUZE78].  They  allow  for  a  wide  variety  of 
model  configurations  and  workloads.  The  model  design  and  the  input  of  the  parameters  are 
performed  in  an  interactive  dialog.  The  solution  methods  are  based  on  local  balance  assump¬ 
tions  [BCMP75],  the  conditions  of  operational  analysis  [DB78],  or  the  mean  value  analysis 
[REIS79].  The  computational  requirements  of  these  solvers  are  relatively  small.  Two  of  these 
packages  are  commercially  available  [KELL73,  BUZE78]. 


3.5  TABULAR  SUMMARY  OF  CASE  STUDIES 

To  summarize  the  case  studies  reviewed,  we  present  some  attributes  of  the  models  of  these 
studies  in  table  2.  The  computational  models  are  described  by  giving  their  classification  vector 
and  their  solution  method  (column  "Solv.").  For  hierarchical  models,  these  attributes  are 
given  for  both  levels.  Further,  the  modeling  level  (column  "Lev."),  the  monitor  type  used,  the 
major  input  parameters,  and  the  major  results  are  tabulated. 


CONCLUSIONS 

Perhaps  the  most  remarkable  observation  arising  from  our  survey  is  that,  despite  much  effort 
at  obtaining  good  approximate  solutions  to  queueing  network  models  not  possessing  product 
form  solutions,  each  case  study  we  have  reviewed  is  based  primarily  on  a  model  with  a  product 
from  solution.  Some  studies  did  not  exploit  the  product  form  in  the  computational  solution. 
Others  treated  more  general  models  by  approximating  them  with  product  form  models. 
However,  all  the  models  actually  used  in  the  numerical  solution  satisfied  the  conditions  of  local 
balance  or  operational  analysis.  Even  among  models  with  product  form  solutions,  load- 
dependent  servers  have  been  used  only  occasionally  in  case  studies.  One  reason  for  this  is  the 
difficulty  of  obtaining  sufficient  information  from  measurement  data  to  characterize  a  load- 
dependent  server.  Measurement  data  also  seldom  adequately  records  how  such  passive 
resources  as  memory  are  used  by  programs.  Advances  in  techniques  for  measuring  and 
monitoring  computer  systems  will  allow  more  extensive  practical  of  the  more  sophisticated  and 
detailed  queueing  network  models  proposed  recently. 
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Queueing  Network  Modelling  of  an  IMS/MVS 
Data  Base/Data  Communications  System 


Lenny  Freilich 


Abstract 

Models  using  queueing  network  representations  have  been  applied  success¬ 
fully  in  the  study  of  computer  systems  in  the  recent  past.  These  models  have 
proven  adequate  in  answering  performance  questions  at  the  operating  system 
level.  The  advantages  of  queueing  network  models  in  the  more  detailed  investi¬ 
gations  of  computer  subsystems  have  not  yet  been  illustrated.  This  paper  illus¬ 
trates  the  modelling  of  one  particular  such  subsystem,  the  data  base/data  com¬ 
munications  system  IMS/MVS.  An  operating  system  level  case  study,  including 
details  on  data  collection,  is  presented.  The  study  uses  analytic  queueing  net¬ 
work  solution  techniques.  Models  at  two  levels  of  detail  are  discussed.  The  first 
model,  containing  only  a  single  coalesced  user  class,  validates  well.  The  second 
model,  in  which  different  user  woarkloads  are  explicitly  represented,  does  not 
validate  as  well  due  to  the  problem  of  obtaining  sufficient  data.  Finally,  we  illus¬ 
trate  the  predictive  capabilities  and  limitations  of  the  models. 


This  paper  is  based  on  the  M.Sc.  thesis,  "A  Queueing  Network  Study  of  an 
IMS/MVS  Data  Base/Data  Communications  System",  March  1979,  by  this  author. 
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1.  Introduction 

Modelling  computer  systems  as  queueing  networks  has  been  successful  in 
recent  years.  The  models  have  traditionally  been  applied  in  the  study  of  high 
level  operating  system  concepts.  As  yet,  there  has  not  been  sufficient  evidence 
that  the  technique  can  be  used  to  study  the  details  of  a  complex  subsystem  of 
an  operating  system,  such  as  a  data  base  management  system.  Because  one  of 
the  advantages  in  the  use  of  queueing  network  models  has  been  the  simple  form 
the  models  have  taken,  it  is  not  clear  whether  they  will  be  sufficient  to  deal  with 
complex  subsystems  appropriately.  In  particular,  the  models  may  be 
insufficient  when  used  in  an  attempt  to  capture  fine  but  appropriate  levels  of  de¬ 
tail. 


This  paper  provides  a  summary  of  an  attempt  to  use  queueing  network 
models  in  the  study  of  the  IMS/MVS  data  base/data  communications  system. 
Complete  details  of  the  study  are  available  in  [FREI79]. 

Section  2  describes  the  operation  of  an  IMS/MVS  system,  the  monitors 
available  for  data  collection,  and  the  particular  environment  under  study.  In 
section  3,  the  results  of  a  single  class  model  of  the  system  are  discussed.  A 
more  detailed  model  of  the  system  in  which  user  workloads  are  explicitly 
represented  is  presented  in  section  4. 


2.  The  IMS/MVS  Environment 

MVS 


The  MVS  operating  system  is  a  multiprogrammed  virtual  memory  operat¬ 
ing  system  permitting  the  concurrent  processing  of  different  types  of  workloads. 
Examples  of  different  workloads  would  be  TSO,  batch,  VTAM,  or  IMS.  It  is  possi¬ 
ble  to  specify  the  level  of  service  each  workload  is  to  receive.  This  allows  the 
system  manager  a  degree  of  control  over  the  turnaround  times  and  response 
times  that  the  users  in  each  workload  can  expect  to  receive.  This  control  was 
possible  to  a  certain  extent  in  earlier  operating  systems  such  as  MVT  (Multipro¬ 
cessing  with  a  Variable  number  of  Tasks),  but  was  accomplished  indirectly.  For 
example,  it  is  possible  to  improve  the  average  TSO  response  time  under  MVT  by 
allocating  additional  TSO  regions,  thus  ensuring  that  TSO  users  spend  a  larger 
percentage  of  time  executing  in  the  multiprogramming  mix,  and  less  time 
queueing  outside  the  system  waiting  for  a  region  to  be  freed.  The  total  resource 
utilization  for  TSO  would  also  increase.  Unfortunately,  it  would  be  difficult  to 
determine  precisely  the  relationship  between  allocation  of  an  extra  TSO  region 
and  TSO  performance.  It  would  also  be  diffcult  to  increase  the  service  to  TSO  by 
a  factor  equivalent  to  adding  less  than  one  entire  region.  In  short,  MVT,  as  a 
representative  early  operating  system,  does  not  have  precise  control  over  per¬ 
formance  attained  by  workload  components. 

This  control  is  a  major  feature  in  MVS.  It  is  possible  to  specify  an  increase 
in  service  to  classes  such  as  TSO  more  directly,  by  indicating  the  amount  of 
resource  usage  the  workload  is  to  receive.  Finer  breakdowns  are  also  possible. 

The  MVS  term  for  a  workload  is  a  performance  group.  Each  performance 
group  may  be  divided  into  periods.  Different  periods  within  a  workload  are  used 
to  distinguish  between  users  in  that  group  with  different  work  requirements,  so 
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that  service  can  be  allocated  accordingly.  It  is  possible  to  allocate  different 
rates  of  service  to  each  period  in  a  performance  group.  This  is  done  by  assign¬ 
ing  each  performance  period  to  a  domain.  As  an  example,  it  is  common  to  split 
the  TSO  performance  group  into  three  periods.  The  first  period  represents  trivi¬ 
al  requests  such  as  editing  functions,  for  which  good  response  time  is  desirable. 
The  second  period  represents  medium  length  requests,  such  as  displaying  sec¬ 
tions  of  files.  The  third  period  represents  long  requests,  such  as  job  compila¬ 
tion.  When  a  TSO  job  begins  executing,  it  receives  the  service  specified  for  the 
first  TSO  period.  After  it  has  used  up  a  predetermined  amount  of  service  (the 
amount  of  service  is  a  function  of  memory  used,  I/O  counts,  and  CPU  time),  the 
job  is  considered  to  be  in  the  second  TSO  period,  at  which  point  it  receives  ser¬ 
vice  at  the  new  rate  specified  for  that  period.  This  is  known  as  domain  migra¬ 
tion.  Similar  specifications  can  be  used  to  allow  for  good  turaround  of  short 
batch  jobs.  Service  accumulation  in  MVS  is  determined  by  continuous  monitor¬ 
ing  of  jobs.  This  is  the  function  of  the  System  Resource  Manager  (SRM). 

The  concept  of  using  domain  migration  to  give  preferred  treatment  to 
subclasses  of  users  within  performance  groups  is  not  available  to  the  same  ex¬ 
tent  in  previous  systems.  Under  MVT,  it  is  possible  to  give  better  service  to  an 
individual  user,  by  basing  CPU  scheduling  on  job  card  information.  Under  MVT, 
it  is  also  possible  to  give  better  service  to  a  class  of  users,  such  as  TSO. 

Neither  method  is  as  general  as  the  ones  provided  by  MVS.  The  service  a 
user  receives  can  be  based  on  the  type  of  job  submitted,  rather  than  the  user 
class  the  job  is  in.  As  an  example,  both  batch  and  TSO  users  can  execute  long 
programs.  Under  MVS  it  is  possible  to  ensure  that  both  receive  the  same  rates 
of  service.  The  operating  system  can  determine  that  a  TSO  job  is  long,  and  allo¬ 
cate  service  at  a  desired  rate.  This  would  not  affect  the  service  short  TSO  re¬ 
quests  would  receive.  Hence  one  has  the  flexibility  of  dealing  separately  with 
jobs  in  a  user  class  that  have  different  resource  requirements. 

All  information  on  performance  groups,  periods,  and  domains  is  contained 
in  a  library  called  the  Installation  Performance  Specification  (IPS).  In  addition 
to  the  above  information,  maximum  and  minimum  multiprogramming  levels  for 
each  performance  group  are  specified.  In  monitoring  the  system,  if  the  SRM 
detects  that  the  balance  of  jobs  in  the  system  is  not  good  (e.g.,  too  many  1/0 
bound  jobs),  then  it  may  be  necessary  to  select  a  job  for  swap-out.  The  mul¬ 
tiprogramming  levels  are  used  as  guidelines  in  this  selection  process.  Swapping 
also  may  occur  when  a  job  has  reached  the  end  of  a  performance  period.  There 
exist  separate  queues  for  each  period.  Hence  if  there  is  another  job  in  a  period 
waiting  to  enter  the  multiprogramming  mix  it  may  be  allowed  to  do  so  and  the 
job  completing  in  the  previous  performance  period  may  be  swapped  out.  Details 
of  modelling  this  process  are  described  in  [BUZE78]. 

The  flow  of  work  within  MVS  is  illustrated  in  figure  1,  and  described  in  the 
following: 

Batch  jobs  (event  1)  may  enter  through  the  Job  Entry  System  (JES).  Ter¬ 
minal  transactions  such  as  TSO  or  IMS  (event  2)  enter  through  the  Telecommuni¬ 
cation  Acess  Method  (TCAM)  or  the  Virtual  Telecommunications  Access  Method 
(VTAM).  Upon  entry,  batch  and  TSO  jobs  queue  outside  of  the  active  multipro¬ 
gramming  mix  (event  3)  until  they  are  permitted  to  enter  by  the  SRM  (event  4). 
Data  base  jobs  are  usually  permitted  to  enter  the  multiprogramming  mix  im¬ 
mediately  (event  5),  and  are  not  under  control  of  the  SRM.  This  is  described  in 
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more  detail  in  the  following  section. 

Once  a  job  is  in  the  multiprogramming  mix,  it  becomes  eligible  for  service 
from  the  CPU  (event  6).  It  is  possible  to  ensure  that  jobs  in  a  particular  period 
receive  priority  for  CPU  scheduling.  After  having  been  scheduled  (event  7),  jobs 
may  queue  for  further  service  from  the  CPU,  or  may  require  service  from  the 
I/O  Supervisor  (IOS)  (event  8).  This  can  occur  if  a  job  page  faults  or  requires  ac¬ 
cess  to  data  on  one  of  the  system’s  secondary  storage  devices. 

If  the  SRM  detects  that  there  are  too  many  jobs  in  the  system,  or  a  job  has 
completed  the  maximum  amount  of  Service  permitted  for  its  domain,  swap  out 
may  occur  (event  9).  The  job  then  leaves  the  multiprogramming  mix  and  queues 
for  re-entry. 

Scheduling  occurs  at  two  levels  in  the  system.  Outside  the  multiprogram¬ 
ming  mix,  jobs  queue  by  performance  group.  Once  inside,  the  jobs  queue  by 
domain.  The  number  and  length  of  job  schedulings  is  a  function  of  the  IPS 
parameters  specified  for  the  job’s  domain  [IBM78]. 


IMS 


IMS/MVS  is  an  IBM  program  product  designed  to  improve  the  user’s  ability 
to  implement  data  base/data  communications  (DB/DC)  applications.  A  data 
base  is  a  collection  of  interrelated  data  elements  that  can  be  processed  by  one 
or  more  applications  [DATE75].  IMS  is  essentially  a  hierarchical  data  base  sys¬ 
tem,  with  limited  amounts  of  networking  permitted  in  order  to  eliminate  data 
redundancy  and  simplify  data  base  traversal.  Detailed  descriptions  of  IMS  in  the 
MVS  operating  environment  are  provided  in  [IBM77a,  IBM77b,  IBM?7c]. 

Data  bases  are  accessed  in  IMS  with  the  use  of  the  Data  Language/I  (DL/I) 
facility.  This  access  is  provided  in  the  form  of  subroutine  calls  embedded  in  a 
host  language  such  as  PL/I,  COBOL,  or  Assembler.  For  example,  a  data  base 
command  such  as  "Get  Unique"  would  be  performed  in  a  PL/I  program  through 
the  PL/I  to  DL/I  interface  and  would  appear  as  the  subroutine  call  CALL 
PLITDLI(’GU’,...). 

IMS  can  operate  under  MVS  in  essentially  two  modes,  a  batch-only  process¬ 
ing  mode  or  a  data  communications  system  mode.  In  the  batch  mode,  programs 
are  scheduled  by  the  operating  system  in  the  same  fashion  as  ordinary  batch 
jobs  and  the  data  bases  are  allocated  to  the  program  executing  according  to  the 
file  disposition  specified.  Two  different  programs  will  not  be  permitted  to  access 
a  particular  data  base  dataset  unless  both  have  specified  share  dispositions  for 
the  file.  Simultaneous  access  would  probably  only  occur  for  read  only  applica¬ 
tions.  In  the  batch  mode  IMS  merely  plays  the  role  of  a  sophisticated  data  ac¬ 
cess  scheme.  The  flow  through  the  operating  system  of  an  IMS  job  in  batch 
mode  is  described  in  figure  2. 

The  following  describes  the  flow  of  events  in  figure  2: 

l)  The  IMS/MVS  batch  control  program  is  invoked  by  MVS  task 
management.  It  supervises  the  loading  of  modules  and  initializes  the 
batch  operating  environment. 
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2)  The  control  program  links  to  a  batch  application  program,  which 
has  been  link  edited  with  the  language  interface. 

3)  When  the  application  program  issues  a  DL/I  call,  control  is  passed 
via  the  language  interface  to  the  program  request  handler.  The  pro¬ 
gram  request  handler  provides  preliminary  checking  of  the  call 
parameters,  and  passes  control  to  the  DL/I  call  analyzer. 

4)  Depending  on  the  function  requested,  the  DL/I  call  analyzer  passes 
control  to  the  appropriate  call  processor  module.  The  DL/I  action 
modules  request  service  from  the  basic  access  modules  and  record 
their  activity  on  the  IMS/MVS  log. 

5)  Optionally,  the  program  can  request  a  checkpoint  to  establish  a 
restart  point.  Checkpoints  are  logged  on  the  IMS/MVS  log  to  enable 
restart  should  that  be  required. 

6)  When  the  application  program  finishes  processing  it  returns  control 
to  the  batch  control  program  for  termination  processing. 

The  batch  control  program  is  re-entrant  and  can  serve  more  than  one  pro¬ 
gram  at  a  time.  Hence  it  is  possible  to  have  several  IMS  batch  jobs  processing 
concurrently.  All  other  functions  for  the  job  are  provided  by  the  MVS  operating 
system.  A  performance  group  can  be  defined  for  IMS  batch  jobs  if  desired,  or 
they  can  be  coalesced  into  the  regular  batch  performance  group,  depending  on 
the  levels  of  service  required. 

The  batch  mode  of  IMS  is  typically  used  when  response  time  is  not  a  criti¬ 
cal  factor  or  when  application  programs  must  process  large  amounts  of  data. 
Under  these  conditions,  the  IMS  batch  mode  can  be  the  most  effective  method  of 
completing  a  required  amount  of  work. 

When  interactive  processing  of  data  is  desired,  the  data  communications 
mode  of  IMS  is  the  appropriate  mode.  Units  of  work  processed  in  this  fashion 
are  known  as  transactions.  The  processing  requirements  of  transactions  are 
typically  quite  small,  and  short  response  times  must  be  provided.  There  are  two 
modes  of  interactively  running  transactions.  In  the  first  mode  the  user  issues  a 
request  from  a  terminal,  invoking  a  sequence  of  events  resulting  in  the  transac¬ 
tion  being  processed.  The  user  can  initiate  further  transactions  before  the 
response  to  the  first  one  has  been  received.  It  is  also  possible  for  the  user  to  ini¬ 
tiate  a  conversational  transaction,  where  the  user's  terminal  is  locked  out  from 
further  input  until  a  response  from  the  transaction  has  been  received.  The  user 
can  then  issue  further  messages  to  the  executing  program. 

Transactions  are  executed  in  address  spaces  that  have  been  generated 
during  system  initialization.  The  following  are  distinguished  in  an  IMS/MVS  sys¬ 
tem  in  the  data  communications  mode. 

1)  The  control  region  (CTL)  contains  the  IMS/MVS  program.  It  con¬ 
trols  the  terminals  and  data  bases. 

2)  The  message  processing  regions  (MPP)  host  the  application  pro¬ 
grams  for  message  driven  processing  of  the  data  bases.  The  MPPs  are 
controlled  by  and  rely  upon  the  CTL  region. 
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3)  The  batch  message  processing  regions  (BMP)  contain  the  applica¬ 
tion  programs  for  batch  processing  of  the  data  bases  managed  by  the 
control  region. 

Once  the  data  communications  system  has  been  initialized,  the  data  bases 
allocated  to  it  cannot  be  accessed  by  programs  other  than  by  going  through  the 
control  region.  Such  data  bases  are  referred  to  as  being  on-line.  For  example,  a 
regular  batch  job  cannot  access  these  data  bases.  It  is  possible,  however,  for 
the  batch  programs  to  use  IMS  to  access  data  bases  not  allocated  to  the  control 
region  while  the  communications  system  is  up  (e.g.,  processing  against  test  data 
bases).  In  order  to  process  batch  requests  against  on-line  data  bases,  BMPs 
must  be  used.  This  type  of  job  is  run  when  a  relatively  large  amount  of  work 
must  be  performed  against  the  data  base  and  the  communications  system  is  up. 
The  user  is  also  not  constrained  to  use  previously  defined  transaction  programs, 
and  can  write  his  own  application. 

In  order  to  initiate  a  transaction,  a  user  must  type  a  transaction  code  from 
a  terminal.  This  causes  a  program  from  the  application  program  library  (APL) 
to  be  loaded  into  a  message  processing  region,  at  which  point  processing  against 
the  data  base  is  performed  through  the  control  region. 

Scheduling  of  requests  and  regions  for  MPP  transactions  is  performed  by 
the  control  region  of  IMS.  Scheduling  for  the  BMP  jobs  is  performed  by  MVS. 
BMP  regions  are  not  generated  with  the  IMS  system,  but  are  created  as  the  need 
arises. 

The  flow  in  an  IMS/MVS  system  is  illustrated  in  figure  3,  and  described  in 
the  following: 

1)  When  an  input  message  or  message  segment  is  received  (event  2), 
the  data  communication  facility  calls  the  common  service  module 
(event  3),  and  the  input  message  is  logged  (event  4)  and  queued  (event 
5). 

2)  When  there  are  input  messages  queued  and  waiting  for  processing, 
and  a  message  processing  region  becomes  available,  control  is  passed 
to  the  scheduling  facility  to  determine  the  application  message  pro¬ 
cessing  program  to  be  scheduled.  The  application  program  is  loaded 
(if  necessary)  into  a  region  and  control  is  passed  to  it. 

3)  The  application  program  subsequently  makes  requests  for  the  input 
message  and/or  data  base  reference  (event  6).  Control  passes  to  the 
DL/I  modules  for  either  message  reference  (event  7)  or  data  base 
reference  (event  8).  The  message  reference  is  accomplished  through 
the  common  service  module. 

4)  While  the  application  program  is  executing,  modifications  can  be 
made  to  the  data  base  (event  8)  and/or  output  messages  may  be 
queued  (events  5  and  7). 

5)  When  the  application  program  terminates  or  requests  another  input 
message,  all  its  queued  output  messages  are  transmitted  to  the  desig¬ 
nated  output  queues  (events  2  and  3).  A  program  may  process  several 
transactions  during  a  single  scheduling. 
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In  the  case  of  conversational  processing,  a  transaction  does  not  terminate 
as  in  the  above.  A  scratchpad  area  (SPA)  must  be  saved  when  the  application 
program  requires  further  input.  At  this  point,  the  SPA  is  saved  and  the  region 
containing  the  application  is  freed  as  though  the  user  issues  a  response  to  mes¬ 
sages  sent,  the  program  corresponding  to  the  transaction  along  with  its 
scratchpad  is  loaded  again  as  if  it  were  a  new  transaction. 


Monitors 

A  variety  of  monitoring  capabilities  is  provided  for  both  IMS  and  MVS  to  aid 
in  performance  studies.  The  most  commonly  used  monitors  for  the  MVS  system 
are  the  Generalized  Trace  Facility  (GTF),  the  Resource  Management  Facility 
(RMF),  and  the  System  Measurement  Facility  (SMF).  Information  for  IMS  systens 
can  be  obtained  with  the  aid  of  the  IMS  Data  Base  (DB)  or  Data  Communications 
(DC)  Monitor,  the  IMS  log  tape,  and  Control/IMS  (C/IMS).  RMF,  SMF,  and  C/IMS 
were  used  in  this  study. 

SMF[IBM76b]  is  an  event  trace  monitor.  The  information  it  provides  is  on 
the  user  level.  Information  collected  is  based  mainly  on  job  step  initiation  and 
termination.  SMF  is  not  a  source  of  great  overhead  when  running,  as  most  of  the 
information  it  requires  can  be  obtained  from  tables  maintained  by  the  SRM. 
This  depends  on  precisely  which  events  are  traced.  SMF  is  typically  used  for  ac¬ 
counting  purposes,  and  provides  information  on  accountable  resource  usage  by 
TSO  and  batch  users. 

I/O  information  recorded  by  SMF  is  in  the  form  of  accountable  logical  I/Os, 
Execute  Channel  Program  (EXCP)  macros,  by  device  for  each  job.  These  EXCPs, 
unfortunately,  do  not  nearly  account  for  all  the  I/O  usage  in  most  systems. 
Similarly,  CPU  usage  by  jobs  does  not  account  for  all  CPU  usage  on  a  system. 

SMF  provides  no  information  on  the  transaction  processing  facility  of  IMS. 
Some  information  however,  is  provided  on  programs  running  in  BMPs.  These 
jobs  are  scheduled  as  regular  batch  jobs  in  the  system,  and  are  accounted  for  as 
such.  Unfortunately,  no  information  is  provided  on  resource  usage  by  IMS 
modules  in  the  control  region  while  performing  work  for  BMPs,  and  this  can 
amount  to  a  substantial  portion  of  processing  requirments  of  such  jobs. 

SMF  records  are  usually  logged  on  tape.  No  data  reduction  routines  are 
available. 

RMF  [IBM76c]  is  a  sampling  monitor  that  collects  information  at  the  sys¬ 
tem  level.  Information  is  provided  on  CPU  activity,  I/O  activity  (channel  and 
device  utilization),  main  storage  activity  (demand  and  swap  paging  statistics), 
and  SRM  activity  (workload).  I/O  activity  reported  is  on  the  basis  of  physical 
I/Os,  corresponding  to  Start  I/O  (SIO)  instructions  executed.  Most  of  the  infor¬ 
mation  RMF  requires  can  be  obtained  from  the  SRM,  and  hence  RMF  does  not 
generate  much  additional  overhead.  Once  again,  this  depends  on  which  statis¬ 
tics  are  being  reported. 

RMF  issues  reports  at  regular  time  intervals.  This  is  the  largest  source  of 
overhead  for  the  monitor,  and  hence  it  is  advisable  to  leave  long  intervals 
between  reports  if  large  numbers  of  system  statistics  are  required.  This  can  be 
reduced  if  only  statistics  on  a  few  devices  are  being  reported.  It  is  usual  to  log 
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the  RMF  reports  with  the  SMF  datasets. 

RMF  can  provide  workload  details  down  to  the  performance  period  level  if 
desired.  Hence  separate  statistics  can  be  obtained  for  a  specific  workload  only 
if  a  separate  performance  group  is  defined  for  that  workload. 

Similar  to  SMF,  the  class  based  information  is  obtained  from  the  SRM,  and 
only  accountable  resource  usage  is  reported.  The  same  remarks  about  BMPs  ap¬ 
ply  to  RMF.  IMS  regions  are  considered  performance  groups  by  MVS,  and  hence 
RMF  attempts  to  provide  information  on  resource  usage  of  the  control  region 
and  message  processing  regions,  but  unfortunately,  most  of  the  work  done  is 
considered  to  be  system  work,  and  hence  very  little  IMS  resource  usage  is  ac¬ 
counted  for.  RMF  cannot  even  report  on  IMS  transaction  counts,  as  it  only 
recognizes  the  regions  as  workloads,  which  appear  as  unending  programs. 

Control/IMS  [BB75]  is  a  non-IBM  product  intended  mainly  for  accounting 
purposes.  It  is  an  event  driven  monitor  and  makes  use  of  much  of  the  informa¬ 
tion  that  is  collected  for  the  IMS  log  tape.  As  a  result,  the  overhead  of  the  moni¬ 
tor  is  quite  low.  Information  such  as  accountable  CPU  usage  and  DL/I  call  statis¬ 
tics  by  transaction  are  provided  on  a  cumulative  basis.  Control/IMS  provides 
some  details  on  overhead  CPU  usage. 

It  is  possible  to  have  the  monitor  run  in  a  detailed  trace  mode  and  provide 
statistics  on  individual  transaction  executions  and  region  usage.  This  is  a  rather 
high  overhead  mode,  and  tremendous  amounts  of  data  can  be  produced  in  a 
short  period  of  time  due  to  the  number  of  transactions  processed  by  most  sys¬ 
tems. 


The  Environment 

The  system  under  study  was  the  University  of  Toronto’s  administrative 
computer  system,  an  IBM  370  running  under  IMS/MVS.  The  system  consisted  of 
a  158  CPU  with  four  megabytes  of  main  memory  and  four  integrated  channels. 
Card  readers,  printers,  and  approximately  eighty  terminals  were  attached  to 
channel  0.  Five  tape  drives  were  attached  to  channel  1,  and  thirteen  disk  drives 
were  shared  by  channels  2  and  3.  There  was  a  plan  to  provide  full  string  switch¬ 
ing  capability  [IBM74]  on  these  channels,  but  at  the  time  the  study  was  per¬ 
formed  the  required  software  had  not  yet  been  completed.  The  result  was  that 
I/O  requests  to  a  disk  could  go  through  either  channel  2  or  3  (channel  2  was  the 
first  choice),  but  the  data  transferred  had  to  be  returned  through  the  same 
channel  the  request  had  come  in  on.  Requests  for  data  transfer  could  thus  be 
delayed  despite  the  fact  that  one  of  the  channels  was  free. 

The  machine  was  required  to  process  two  types  of  applications,  those  relat¬ 
ing  to  students  and  courses,  such  as  course  enrollment  and  student  records, 
and  those  relating  to  financial  matters  such  as  payroll.  Both  the  batch  and  in¬ 
teractive  interfaces  were  required.  The  IMS  data  base  system  was  used  to  struc¬ 
ture  most  of  the  applications  and  was  responsible  for  most  of  the  work  on  the 
machine,  the  remainder  being  made  up  of  system  related  work  and  program 
testing. 

The  workload  on  the  system  varied  greatly.  Payroll  processing  would  oc¬ 
cur  at  regular  intervals,  with  little  payroll  work  required  at  other  times.  The 
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same  was  true  of  the  registration  related  work,  which  made  up  the  single  largest 
workload  component.  The  system  had  to  handle  the  peak  load  produced  during 
registration.  During  the  remainder  of  the  year,  the  system  would  have  a  great 
deal  of  idle  time,  as  during  these  periods  the  workload  requirements  were  far 
from  the  peak. 

The  computer  installation  ran  the  communications  mode  of  IMS  during  the 
day,  and  IMS  batch  applications  were  processed  overnight.  In  addition,  TSO  and 
batch  users  were  on  the  system  during  both  modes  of  operation.  The  batch 
workload  was  split  into  two  performance  periods,  and  the  TSO  workload  three. 
Each  of  the  periods  was  assigned  disinct  performance  objectives  so  that  the  TSO 
and  batch  periods  were  assigned  to  different  MVS  domains.  This  was  important 
during  the  data  collection  stage  of  the  study  because  the  multiple  class  model  in 
section  4  required  user  class  based  information.  Most  of  the  system  monitors 
supplied  information  broken  down  by  domain,  so  in  this  case,  the  information 
was  available  for  each  user  class. 

Interactive  job  alteration  and  submission  was  performed  mostly  with  the 
use  of  the  Job  Development  System  (JDS).  This  system  consisted  of  a  number  of 
IMS  transaction  programs  to  handle  the  various  commands  required  in  such  a 
facility.  A  data  base  consisting  of  user  programs  was  maintained.  Most  of  these 
programs  were  to  be  run  in  BMPs.  A  special  transaction  program  was  used  to 
submit  these  programs  as  batch  jobs  to  the  MVS  scheduler.  This  was  necessary 
as  BMP  jobs  cannot  be  passed  directly  to  MVS  from  the  IMS  system. 

There  were  three  types  of  batch  jobs  on  the  system.  One  group  ran  as 
BMPs.  A  second  group  consisted  of  program  compilations.  The  third  group  con¬ 
sisted  of  jobs  that  were  running  as  IMS  batch  jobs,  and  were  executing  against 
offline  test  data  bases. 

The  IMS  workload  had  been  split  into  three  classes  for  scheduling  pur¬ 
poses.  These  classes  were  grouped  by  expected  processing  time,  the  first  class 
containing  the  shortest  transactions,  and  the  third  the  largest.  Three  message 
processing  regions  were  initialized.  The  first  region  was  allowed  to  process  tran¬ 
sactions  from  only  the  first  class.  The  second  region  was  allowed  to  process 
transactions  from  either  the  first  or  second  class,  and  the  third  region  was  al¬ 
lowed  to  process  transactions  from  either  the  second  or  third  class.  This  en¬ 
sured  the  long  running  transactions  would  be  processed  serially,  and  that  short 
transactions  would  always  be  running  if  possible. 

In  addition  to  the  above  factors,  the  regions  were  also  assigned  different 
MVS  dispatching  priorities.  The  region  processing  only  class  one  had  been  given 
a  higher  priority  than  the  other  two  regions.  This  tended  to  ensure  further  that 
short  transactions  received  preferential  treatment.  There  was,  however,  only  a 
small  difference  in  the  priorities  assigned.  Hence  the  MVS  dispatching  factor 
was  likely  not  as  important  to  transaction  scheduling  as  the  IMS  region 
specifications. 

The  first  period  TSO  transactions  were  assigned  a  higher  priority  than  the 
IMS  dependent  regions,  and  TSO  transactions  in  the  remaining  periods  lower. 
The  batch  periods  and  the  third  TSO  period  were  assigned  the  same  priority, 
lower  than  TSO  period  two.  The  general  effect  was  that  IMS  and  short-to-medium 
TSO  users  received  better  service  than  the  batch  class  users.  The  minimum 
multiprogramming  level  specified  for  first  period  TSO  was  one,  however,  which 
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was  not  enough  to  ensure  that  arriving  TSO  requests  were  swapped  in  upon  ar¬ 
rival  to  the  system.  The  minimum  multiprogramming  level  for  IMS  was  set  to 
the  maximum,  ensuring  that  MVS  would  pass  all  arriving  IMS  transactions  to  the 
IMS  control  region,  which  could  then  determine  scheduling.  The  IMS  regions 
were  made  non-swappable. 

In  addition  to  batch,  TSO,  and  IMS,  workloads  were  specified  for  MVS  sub¬ 
systems  such  as  JES2  and  VTAM. 

Most  computer  systems  cire  in  a  constant  state  of  change.  This  is  particu¬ 
larly  important  in  obtaining  measurement  data,  as  measurement  data  gathered 
at  different  times  may  not  be  mutually  comparable.  This  tends  to  complicate 
workload  analysis  and  projection.  The  system  under  study  was  evolving,  and 
several  changes  had  occurred  in  the  recent  past,  with  several  more  planned.  As 
the  workload  on  the  system  had  been  continually  increasing,  changes  were 
necessary  to  enable  workload  processing  and  provision  for  acceptable  user 
response.  The  following  two  sections  attempt  to  predict  the  performance  effects 
of  some  of  these  changes. 

The  installation  had  started  out  with  a  155  processor.  This  was  followed  by 
a  158  CPU  at  the  time  of  the  study,  and  plans  existed  to  move  up  to  a  3031  pro¬ 
cessor  with  two  additional  megabytes  of  main  memory.  A  3031  processor  is  11- 
15%  faster  than  a  158[IBM77e]. 

It  was  felt  that  1/0  was  a  major  source  of  delay  during  certain  periods  of 
the  day..  Earlier,  the  system  had  maintained  disk  packs  separately  on  channels 
2  and  3.  This  had  led  to  attempts  to  balance  the  loads  on  the  channels  by  rear¬ 
ranging  system  datasets.  Unfortunately,  channel  utilization  could  still  be  highly 
unbalanced  at  particular  periods.  With  a  full  string  switching  capability,  the 
channel  loads  could  be  dynamically  balanced. 

There  were  other  software  changes.  The  JDS  system  had  been  developed 
before  the  introduction  of  the  MVS  operating  system.  Included  in  TSO  under 
MVS  is  the  TSO  Structured  Programming  Facility  (SPF),  which  has  the  usual 
functions  of  TSO  but  also  provides  software  for  handling  full  screen  editing  at 
terminals.  TSO  SPF  is  more  efficient  and  flexible  than  JDS.  As  a  result,  there  ex¬ 
isted  an  on-going  effort  to  wsitch  users  from  JDS  to  SPF.  At  the  time  of  the 
study,  TSO  use  was  largely  restricted  to  systems  programmers,  with  most  of  the 
general  user  community  still  using  JDS.  As  the  introduction  of  SPF  had  been 
fairly  recent,  the  users  were  still  somewhat  unsophisticated,  and  the  workload 
on  the  component  was  light,  likely  not  indictive  of  future  use. 

Tuning  efforts  by  the  computer  centre  provided  a  final  source  of  change  to 
the  system.  The  IPS  specifications  were  slight  modifications  of  defaults  provided 
by  IBM.  The  computer  centre  had  not  yet  decided  precisely  what  level  of  service 
each  user  class  should  receive,  and  hence  IPS  values  were  being  modified.  The 
major  area  of  attention  was  in  establishing  dispatching  priorities.  These  were 
varied,  and  the  results  observed.  The  TSO  first  period  scheduling  priority  had  in¬ 
itially  been  lower  than  that  of  the  IMS  dependent  regions.  Response  time  for 
trivial  TSO  requests  was  felt  to  be  inadequate,  and  the  scheduling  priority  was  in¬ 
creased  until  an  adequate  response  time  was  observed. 

The  crucial  issue  to  the  computer  centre  personnel  was  whether  the  sys¬ 
tem  was  powerful  enough  to  process  the  workload  due  in  the  next  peak  registra- 
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tion  period.  To  provide  an  accurate  projection  of  the  performance  of  a  comput¬ 
er  system  in  the  future,  it  is  imperative  that  an  accurate  projection  of  the  fu¬ 
ture  workload  be  obtained.  This  is,  in  general,  not  a  simple  task.  The  usual 
course  is  to  extrapolate  workload  information  from  the  past.  This  is  difficult  if 
the  system  has  been  undergoing  changes  that  affect  the  workload.  For  example, 
TSO  response  times  might  be  made  significanly  better  than  JDS  response  times 
if  first  period  TSO  were  given  a  higher  priority.  A  number  of  users  might  then  be 
encouraged  to  switch  systems,  resulting  in  a  workload  shift  from  IMS  to  TSO. 
This  is  a  factor  that  may  be  overlooked  in  the  extrapolation  process.  There  are 
a  number  of  other  system  changes  that  would  have  similar  effects. 

Workload  projection  for  our  system  is  simplified  because  the  IMS  subsys¬ 
tem  dominates  system  resource  usage  during  peak  period.  The  workload  re¬ 
quirement  during  registration  could  be  expressed  in  terms  of  the  number  of 
transactions  of  given  types  to  be  processed  over  a  certain  period  of  time.  Hence 
the  key  issue  is  reduced  to  determining  how  long  the  IMS  communications  re¬ 
gion  must  be  kept  up  in  order  to  process  that  workload.  As  one  of  the  functions 
of  an  interactive  system  is  to  provide  user  efficiency,  it  is  usual  to  consider  ex¬ 
pected  response  time  in  a  system  as  well. 


3.  Single  Class  Model  and  Results 

A  queueing  network  model  with  one  coalesced  workload  class  was  con¬ 
structed  in  a  first  attempt  to  study  the  system.  Such  a  model  can  be  useful  in 
answering  general  questions  (those  not  explicitly  involving  the  distinct  work¬ 
loads)  and  can  be  an  aid  in  determining  the  level  of  detail  required  in  successive 
models.  A  single  class  model  also  is  useful  for  assessing  measured  data. 

The  study  was  performed  based  on  the  system  during  the  day  on  an  off- 
peak  period,  with  the  communications  system  up.  The  queueing  network 
configuration  used  is  illustrated  in  figure  4.  Obtaining  the  data  required  for  this 
model  was  relatively  straightforwrd.  The  monitors  SMF,  RMF,  and  C/IMS  were  al¬ 
ways  running,  and  were  capable  of  obtaining  the  required  values. 

The  information  required  included  physical  access  counts  and  utilizations 
of  all  devices  (I/O  and  CPU).  Job  completion  counts  and  mean  multiprogram¬ 
ming  levels  were  required  as  well. 

The  communications  system  was  up  for  a  period  of  just  over  eleven  hours 
during  the  day  of  study.  As  C/IMS  collected  data  only  during  this  period,  it  was 
necessary  to  obtain  the  data  from  the  other  monitors  over  the  identical  interval. 
SMF  provides  a  time  stamp  with  each  record  issued,  and  hence  it  was  possible  to 
select  a  subset  of  the  dat  provided.  RMF  is  a  sampling  monitor  and  issues 
records  only  at  predetermined  intervals.  The  interval  size  was  set  to  30 
minutes,  with  3600  samples  per  interval.  RMF  will  also  issue  a  record  when  the 
operating  system  is  shut  down.  This  was  done  when  the  communications  mode 
was  taken  down,  and  hence  a  final  RMF  record  covering  a  period  of  less  than  30 
minutes  was  obtained. 

RMF  supplied  utilizations  of  all  devices,  as  welll  as  the  number  of  physical 
accesses  to  each  I/O  device  and  channel.  SMF  supplied  the  job  counts  and 
residency  times  for  batch  and  TSO  jobs,  and  C/IMS  did  the  same  for  IMS  transac¬ 
tions.  The  mean  multiprogramming  levels  were  obtained  from  the  sums  of  the 
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figure  4 
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residency  times. 

RMF  supplies  job  counts  as  well,  but  with  a  slightly  different  definition. 
SMF  provides  an  actual  count  of  the  batch  jobs  and  TSO  commands  entered. 
RMF  reports  the  number  of  times  that  the  SRM  began  to  count  service  accumu¬ 
lation  by  a  task.  This  usually  occurs  at  the  start  of  each  new  job  or  command, 
but  can  occur  at  the  start  of  a  job  step  or  in  the  middle  of  a  command  under 
certain  conditions  [IBM77d].  In  general,  RMF  will  provide  a  larger  value  than 
SMF.  The  SMF  values  were  used  in  this  study  as  these  correspond  to  users’  job 
counts. 

A  range  of  values  was  provided  for  the  batch  and  TSO  residency  times,  be¬ 
cause  SMF  supplies  two  figures  that  might  be  interpreted  as  such.  The  lower 
value  corresponds  to  the  time  that  the  jobs  were  actually  in  memory.  The 
higher  value  represents  the  amount  of  time  elapsed  since  the  SRM  first  admitted 
the  job  to  the  multiprogramming  mix.  It  is  not  entirely  clear  which  value  should 
be  used  to  obtain  the  average  multiprogramming  level  required  as  input  to  a 
closed  queueing  network  model.  Even  though  a  job  is  not  in  the  multiprogram¬ 
ming  mix,  it  still  may  be  using  system  resources,  such  as  during  spooling  or 
swapping.  On  the  other  hand,  the  higher  value  includes  the  time  spent  by  a  job 
outside  the  multiprogramming  mix  after  being  swapped  out.  The  model  was 
solved  over  the  range  encompassed  by  the  limits. 

A  solution  par  kage  based  on  Reiser’s  mean  value  technique[REIS79]  was 
used  to  solve  the  model.  Multiprogramming  levels  zero  through  nine  were  input. 
Values  for  intermediate  fractional  multiprogramming  levels  were  obtained  by 
linear  interpolation  of  the  two  surrounding  integral  points.  The  performance 
measures  for  validation  were  throughput  and  channel  and  CPU  utilization.  The 
disk  utilizations  are  not  meaningful  due  to  the  service  time  adjustments  in  the 
input.  The  results  are  presented  in  table  1,  and  compared  to  the  measured 
values. 

The  results  are  quite  close,  and  indicate  that  for  the  queueing  network 
model  the  multiprogramming  level  should  be  chosen  as  somewhere  between  the 
memory  residence  time  and  SRM  time.  Other  results  such  as  tape  utilizations 
were  equally  close. 

Having  obtained  and  validated  such  a  model,  the  next  step  is  to  use  the 
model  as  a  prediction  tool,  and  determine  how  the  system  would  perform  in  an 
altered  environment.  As  the  model  is  a  rather  simple  one,  it  is  not  possible  to 
use  it  in  predicting  the  performance  effects  of  all  the  changes  listed  previously. 

The  model  can  be  used  to  determine  the  general  effects  of  increased  work¬ 
load.  Figure  5  illustrates  the  effects  on  throughput  and  response  time  of  in¬ 
creases  in  the  multiprogramming  level.  The  throughput  is  given  in  the  number 
of  transactions  processed  per  day  as  during  the  day  of  measurement,  i.e.,  with 
the  communications  system  up  for  approximately  11  hours  and  15  minutes.  The 
increase  in  multiprogramming  level  represents  an  increase  in  the  workload  lev¬ 
el.  As  can  be  observed,  diminishing  returns  are  experienced  as  the  workload  is 
increased  and  the  system  throughput  asymptotically  approaches  a  capacity 
value. 


The  graph,  however,  probably  does  not  accurately  describe  what  actually 
occurs  at  high  workload  levels.  This  is  because  in  paging  systems,  as  too  many 
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jobs  enter  the  multiprogramming  mix,  memory  becomes  overcommitted,  and 
thrashing  takes  place.  Jobs  in  the  system  would  then  experience  long  delays  in 
queueing  for  the  paging  device,  with  the  effect  that  system  throughput  would  be¬ 
gin  to  decrease.  This,  however,  is  not  the  case  in  MVS[BUZE78].  One  of  the  pur¬ 
poses  of  the  multiprogramming  level  specification  in  the  IPS  is  to  specify  to  the 
SRM  that  jobs  be  held  back  or  swapped  out  of  the  system  when  such  events  take 
place.  Hence  an  increased  workload  level  does  not  necessarily  correspond  to  an 
increased  multiprogramming  level  after  a  certain  point,  and  the  response  times 
of  jobs  would  begin  to  have  a  significant  component  corresponding  to  waiting 
outside  of  the  multiprogramming  mix,  awaiting  scheduling  by  the  SRM.  A  similar 
effect  occurs  in  the  case  of  IMS  transactions,  as  there  can  only  be  as  many  jobs 
resident  as  there  are  IMS  dependent  regions. 

Increased  workload  levels  in  the  case  of  this  particular  model  corresponds 
to  proportional  increases  in  the  number  of  programs  in  each  user  workload.  It 
is  assumed  that  the  jobs  all  have  identical  characteristics.  Hence  the  model 
does  not  accurately  represent  what  occurs  when  the  workload  on  the  system  is 
the  highest,  as  during  registration,  most  of  the  jobs  running  are  IMS  jobs.  These 
use  considerably  less  system  resources  than  batch  jobs.  Hence,  despite  the  fact 
that  the  throughput  limit  on  the  graph  occurs  at  approximately  30,000  jobs,  this 
does  not  mean  that  it  is  impossible  to  process  more  than  30,000  IMS  transac¬ 
tions.  This,  in  fact,  is  done  during  registration. 

The  fact  that  the  different  workloads  have  different  resource  requirements 
can  be  represented  only  indirectly  in  a  single  class  model.  This  can  be  achieved 
by  determining  what  the  effect  of  an  increase  in  the  number  of  jobs  of  a  given 
workload  would  be  in  terms  of  the  overall  multiprogramming  level.  One  could 
then  decide  what  multiprogramming  level  should  be  used  when  the  workload  is 
increased.  It  is  difficult  to  estimate  what  the  effect  of  an  increase  would  be, 
however.  The  results  of  the  model  would  probably  not  be  accurate  as  the 
resource  requirements  of  the  jobs  may  not  be  in  proportion  to  their  multipro¬ 
gramming  level. 

The  model  can  be  used  to  understand  performance  at  higher  workload  lev¬ 
els  by  pointing  out  the  system  bottleneck.  This  is  the  device  (represented  in  the 
model)  with  the  highest  utilization.  It  can  be  shown  [DB78]  that  system  perfor¬ 
mance  will  show  the  most  improvement  if  the  bottleneck  is  removed.  For  our 
system,  the  CPU  is  clearly  the  bottleneck.  Hence  changes  elsewhere  in  the  sys¬ 
tem  will  not  be  as  helpful  as  if  the  CPU  speed  were  increased.  Unfortunately, 
this  also  tends  to  be  the  most  expensive  change. 

The  effect  of  the  158  to  3031  upgrade  can  be  represented  in  the  model  by 
decreasing  the  CPU  mean  service  times.  The  results  of  doing  this  are  presented 
in  the  original  study,  where  a  graph  similar  to  that  in  figure  5  is  produced  for  a 
system  running  with  a  3031  CPU. 

The  results  show  that  the  capacity  of  the  158  is  approximately  equal  to 
170%  of  the  measured  workload,  achieved  with  a  response  time  of  5.5  seconds. 
The  3031,  however,  would  have  a  capacity  equal  to  over  190%  of  the  measured 
workload  at  which  point  a  response  time  of  5.0  seconds  could  be  expected. 

The  model  could  be  used  in  the  prediction  of  system  performance  when 
the  string  switching  capability  was  implemented.  This  could  be  achieved  by  run¬ 
ning  a  similar  model  with  balanced  channel  counts.  The  likely  effect  would  be 
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higher  throughput  for  a  given  multiprogramming  level,  and  hence  an  improved 
response  time. 

Even  with  the  3031  processor,  device  utilizations  indicate  that  the  CPU 
would  still  be  the  system  bottleneck.  The  implementation  of  string  switching 
could  still  be  effective,  however.  It  is  possible  that  the  system  is  I/O  bound  at 
times  when  most  of  the  jobs  in  the  system  are  run  through  IMS.  Under  such  cir¬ 
cumstances,  it  is  possible  that  the  channels  would  become  the  system 
bottlenecks,  in  which  case  the  channel  upgrade  would  effectively  improve  per¬ 
formance. 

An  upgrade  that  presents  modelling  difficulties  is  a  memory  increase. 
There  existed  a  plan  to  go  from  the  four  megabyte  configuration  on  the  150  to  a 
six  megabyte  configuration  on  the  3031.  This  is  likely  to  produce  a  number  of 
effects.  The  number  of  counts  to  the  paging  device  should  decrease,  as  users 
would  be  able  to  obtain  larger  portions  of  main  memory,  and  be  able  to  keep 
pages  longer.  This  would  reduce  residency  times,  and  hence  increase 
throughputs.  Alternatively,  more  programs  could  be  activated,  again  resulting 
In  increased  throughput.  It  is  difficult  to  determine  precisely  what  the  new  job 
behaviour  would  be,  however.  If  one  could  predict  the  paging  device  usage  in  a 
system  with  more  main  memory,  it  would  be  possible  to  use  the  existing  model 
simply  by  decreasing  the  number  of  paging  device  counts  per  job. 

The  single  class  model  is  not  useful  in  determining  the  effects  of  the  TSO 
shift,  nor  is  it  an  aid  in  predicting  precisely  the  system  performance  during  the 
peak  workload  period.  For  such  a  study,  a  multiple  class  model  is  required. 


4.  Multiple  Class  Model  and  Results 

It  was  possible  with  the  single  class  model  to  compare  performance  of  the 
158  with  a  3031.  This  is  because  the  CPU  was  explicitly  represented  as  a  queue 
and  server.  The  same  is  true  of  the  disks  in  answering  questions  about  string 
switching.  Hence  the  level  of  detail  with  respect  to  hardware  was  adequate  (ex¬ 
cept  for  the  memory  issues). 

The  key  questions  that  the  single  class  model  was  unable  to  answer  satis¬ 
factorily  involved  the  TSO  SPF  workload  shift  and  the  capacity  workload.  In  the 
case  of  the  capacity  questions,  it  would  be  useful  to  be  able  to  express  the  sys¬ 
tem  capacity  in  terms  of  the  maximum  number  of  jobs  that  could  be  processed 
in  each  user  workload.  Since  the  computer  centre  had  an  idea  of  what  the  peak 
workloads  were,  it  would  then  be  possible  to  determine  whether  all  the  required 
work  could  be  accomplished  within  the  time  constraints.  An  example  of  a  peak 
workload  specification  would  be  100,000  IMS  transactions  per  day  and  batch  and 
TSO  workload  requirements  as  during  the  period  of  measurement.  In  addition  to 
determining  whether  this  workload  is  within  the  capacity  of  the  158,  it  is  useful 
to  be  able  to  determine  response  times  for  the  subsystems  involved. 

Details  of  the  user  workloads  (batch,  IMS  transactions,  and  TSO)  were  in¬ 
troduced  in  a  multiple  class  model.  It  was  thus  possible  to  express  the  workload 
to  the  model  in  terms  of  these  classes.  The  second  model  had  the  same 
configuration  as  the  first.  The  token  flowing  through  the  system,  however, 
represented  jobs  from  one  of  the  user  workloads,  instead  of  coalesced  jobs. 
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The  data  required  for  the  model  was  similar  in  form  to  that  of  the  first,  ex¬ 
cept  that  the  information  had  to  be  broken  down  by  user  class.  For  example, 
the  number  of  visits  and  the  total  service  at  each  of  the  hardware  resources  was 
required  for  each  of  batch,  IMS,  and  TSO.  The  same  was  true  of  multiprogram¬ 
ming  levels  and  job  counts. 

In  the  case  of  the  first  model,  because  the  coalesced  class  was  invented  for 
the  purposes  of  the  model,  the  job  counts  and  multiprogramming  levels  were  ob¬ 
tained  by  summing  the  class  based  information  (as  none  of  the  monitors  directly 
supplied  this  information).  No  additional  information  on  these  parameters  is  re¬ 
quired  for  the  multiple  class  model.  Total  service  time  and  visit  counts,  howev¬ 
er,  were  measured  by  RMF  without  regard  to  the  job  class  that  was  responsible 
for  using  that  device.  This  is  insufficient  in  the  case  of  a  multiple  class  model. 

None  of  the  monitors  in  use  on  the  system  provided  a  summary  of  physical 
counts  to  devices  by  class.  As  indicated  in  section  3,  however,  information  was 
provided  on  accountable  logical  accesses.  It  was  therefore  necessary  to  use  this 
information  combined  with  knowledge  of  class  behaviour  to  estimate  the  values 
required  for  the  model.  This  was  a  difficult  task  because  it  was  not  possible  to 
determine  precisely  the  relationship  between  physical  and  logical  counts  to  the 
I/O  devices.  The  issue  was  further  complicated  because  the  accountable 
accesses  represented  only  a  small  portion  of  the  total  number  of  accesses,  and 
the  remaining  I/O  overhead  had  to  be  distributed  among  the  classes.  It  was  not 
clear  what  the  I/O  overhead  associated  with  each  of  the  subsystems  running  the 
classes  was. 

In  other  studies  [K3EN77.ROSE76]  there  have  been  attempts  to  define  a 
EXCP-SIO  ratio  and  use  this  to  allocate  some  of  the  counts  to  a  device.  The 
remaining  counts  can  then  be  distributed  by  using  information  about  the  con¬ 
tents  of  the  disks  and  other  system  information.  This  was  not,  however,  possible 
in  this  study  as  no  such  information  provided  about  the  IMS  class. 

Given  the  data  available,  all  that  could  be  done  for  the  disks  was  to  allocate 
the  SIOs  until  results  close  to  those  measured  were  achieved.  The  same  was 
true  of  the  CPU  allocation  (although  some  information  was  provided  by  SMF). 
Such  a  validation  procedure  does  not  lead  to  a  great  deal  of  confidence  in  the 
model.  If  the  values  assigned  are  realistic,  however,  the  model  can  still  be  use¬ 
ful  in  determining  trends  in  system  performance.  Unfortunately,  this  may  not 
be  much  of  an  improvement  over  intuition.  The  resulting  model  was  useful  be¬ 
cause  it  illustrated  how  the  questions  posed  earlier  could  be  answered.  The 
problems  of  the  performance  study  are  then  reduced  to  obtaining  the  necessary 
data.  GTF  and  DC  Monitor  are  capable  of  providing  the  required  information. 
Their  overhead  involved,  however,  might  make  a  study  during  a  production 
period  impossible. 

The  model  was  run  with  all  combinations  of  multiprogramming  levels  1  and 
2  for  batch,  0  and  1  for  TSO,  and  0  and  1  for  IMS.  The  resulting  values  were 
linearly  interpolated  to  obtain  the  results  for  fractional  multiprogramming  lev¬ 
els.  It  can  be  shown  that  the  order  of  interpolation  among  classes  is  not  impor¬ 
tant  [DM72].  The  multiprogramming  levels  for  batch  and  TSO  were  those  based 
on  the  SRM  time  because  these  gave  the  best  results  in  the  previous  study.  The 
results  of  the  model  are  contained  in  table  2. 

The  batch  and  IMS  throughputs  were  low,  and  the  TSO  throughput  high. 
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This  was  probably  due  to  allocating  too  much  CPU  time  to  batch  and  IMS.  This 
explains  the  low  utilization  of  channel  2,  as  batch  and  IMS  were  responsible  for 
most  of  the  I/O  on  the  system.  Channel  3  utilization  did  not  turn  out  quite  as 
low  as  it  was  accessed  frequently  by  TSO  jobs,  compensating  for  under  utilization 
due  to  low  batch  and  IMS  throughputs. 

Parallelling  the  study  involving  the  single  class  model,  the  multiple  class 
model  was  used  to  investigate  system  capacity  and  performance  at  high  work¬ 
load  levels.  The  model  was  also  used  to  compare  158  performance  to  that  on  a 
system  with  a  3031  CPU. 

The  model  was  run  with  all  combinations  of  IMS  multiprogramming  levels  0 
through  8,  TSO  multiprogramming  levels  0  and  1,  and  batch  multiprogramming 
levels  of  1  through  3.  The  model  was  also  run  with  both  batch  and  TSO  multipro¬ 
gramming  levels  set  to  0  and  IMS  multiprogramming  levels  0  through  8  in  order 
to  establish  an  upper  bound  for  IMS  performance. 

Figure  6  is  a  plot  of  IMS  throughput  for  a  time  period  equivalent  to  that 
during  the  measurement  day  against  IMS  multiprogramming  levels  for  each  of 
the  TSO  and  batch  multiprogramming  level  combinations.  The  results  are  simi¬ 
lar  to  those  in  figure  5.  The  throughput  increases  with  increased  multiprogram¬ 
ming  levels  and  levels  off  as  the  system  approaches  capacity.  The  graph  illus¬ 
trates  that  it  would  be  possible  to  process  100,000  IMS  transactions  only  if 
remaining  work  on  the  system  was  kept  to  a  minimum.  This  is  unlikely,  however, 
as  the  batch  system  is  required  during  registration  to  run  BMPs.  TSO  work,  how¬ 
ever,  could  be  kept  to  a  minimum  on  the  system  during  registration.  A  similar 
graph  produced  for  a  3031  CPU  showed  that  1,000,000  IMS  transactions  could  be 
processed  on  the  3031  even  with  some  batch  and  TSO  workload  components. 

The  model  could  also  be  used  to  answer  questions  about  a  shift  from  JDS  to 
TSO  SPF.  This  could  be  done  by  decreasing  the  IMS  component  of  the  workload 
and  increasing  the  TSO  component  in  the  model.  Graphs  similar  to  those  dis¬ 
cussed  above  could  be  plotted  giving  response  for  the  system  under  varying 
workloads.  Detailed  data  concerning  the  number  of  jobs  shifted  would  be  re¬ 
quired  in  order  to  obtain  meaningful  results. 

As  was  the  case  for  the  single  class  model,  the  multiple  class  model  could 
be  used  to  predict  the  effect  of  the  string  switching  implementation.  This  would 
be  achieved  by  balancing  the  distribution  of  1/0  calls  to  the  two  channels.  Un¬ 
like  the  single  class  model,  however,  the  multiple  class  model  would  provide 
results  on  the  effects  to  each  user  class. 


5.  Conclusions 

In  this  paper  we  have  presented  an  attempt  to  model  the  IMS/MVS  data 
base/data  communications  system  at  the  operating  systems  level,  using  a  net¬ 
work  of  queues  model  and  an  analytic  solution  technique.  Queueing  network 
case  studies  have  illustrated  that  relatively  simple  models  can  be  adequate  in 
answering  typical  performance  questions.  It  is  difficult  to  draw  the  same  conclu¬ 
sion  based  on  the  study  presented  here.  It  is,  however,  possible  to  draw  other 
conclusions. 

The  major  stumbling  block  in  the  study  proved  to  be  the  acquisition  of 
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suitable  data  for  the  model.  This  was  caused  by  several  factors.  The  SMF,  RMF, 
and  C/IMS  monitors  were  not  designed  to  provide  the  values  required  for  queue¬ 
ing  network  models.  They  are  useful  in  providing  accounting  information  and 
some  data  for  performance  studies.  Most  of  the  data  provided  is  on  the  basis  of 
logical,  not  physical,  I/Os.  To  use  this  information,  the  queueing  network 
modeller  must  attempt  to  establish  a  correspondence  between  the  two.  This  in¬ 
volves  estimates  based  on  knowledge  of  the  contents  of  the  secondary  storage 
devices.  This  method  is  insufficient  for  increasingly  complex  systems.  It  is  a 
much  more  difficult  task  to  map  logical  data  base  I/Os  (DL/I  calls)  to  physical 
I/Os.  If  queueing  network  models  of  complex  systems  are  to  be  used  with  any 
degree  of  success,  it  is  essential  that  accurate  data  be  obtained. 

The  problem  of  obtaining  suitable  data  is  not  due  to  a  lack  of  monitors. 
GTF  and  DC  Monitor  in  trace  mode  are  capable  of  providing  the  counts  required 
for  a  queueing  network  model.  The  problem  with  these  monitors  is  that  because 
of  the  high  overhead  they  introduce,  only  a  few  values  can  be  traced  at  a  time. 
The  high  overhead  restricts  the  usefulness  of  such  monitors  for  this  type  of 
study,  in  which  all  measurements  took  place  while  the  system  was  on-line.  It 
would  not  be  possible  to  monitor  the  system  in  this  fashion  for  an  extended 
period  of  time. 

The  problems  involved  in  studying  a  system  can  be  reduced  if  benchmarks 
are  available.  It  would  then  be  possible  to  reproduce  results,  and  one  could  run 
the  system  several  times,  monitoring  a  small  number  of  variables  during  each 
attempt.  This  process  would  eliminate  the  problem  of  a  changing  workload  en¬ 
vironment  affecting  data  consistency.  A  further  advantage  would  be  that  im¬ 
provements  to  the  system  could  be  tested  in  a  controlled  environment.  An  im¬ 
portant  factor  in  this  approach  is  a  suitable  benchmark.  However,  there  are 
difficulties  in  determining  what  type  of  job  mix  is  suitable[CHU79]. 

Given  enough  time  and  effort,  the  problem  of  obtaining  suitable  data  for  a 
queueing  network  model  can  usually  be  solved  to  any  degree  of  detail.  There¬ 
fore,  it  is  reasonable  to  ask  whether  such  models  can  be  used  to  answer  ques¬ 
tions  likely  to  be  important  to  a  computer  installation.  This  study  has  shown 
that  this  can  be  done  for  many  such  questions.  It  was  possible  to  predict  system 
performance  under  any  workload  the  computer  centre  could  describe  in  terms 
of  user  classes.  The  models  were  also  capable  of  explicitly  addressing  the  issue 
of  hardware  changes,  except  in  the  case  of  the  memory  upgrade.  Finally,  the 
model  could  be  used  to  consider  software  issues,  such  as  determining  the  effects 
of  increasing  the  TSO  workload  on  the  system. 
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RES  TIME  SRM  TIME 


MPL=  1.909 

MPL-2.000 

MPL-2.020 

MEASURED 

%ERR 

7aERR 

7*ERR 

THROUGHPUT 

16154  -2.6 

16609  +.1 

16706  +.7 

16586 

CPU  UTIL 

.571  -3.7 

.594  +.2 

.597  +.7 

.5929 

CH2  UTIL 

.218  -3.9 

.227  -.9 

.228  +.5 

.2272 

CH3  UTIL 

.046  -4.2 

.048  -.2 

.048  -.2 

.0481 

Table  1  Single  Class  Model  Results 


MODEL 

MEASURED 

RELATIVE  TERROR 

Throughputs 

BATCH 

263 

274 

-4.0 

(jobs) 

TSO 

5829 

5376 

+8.4 

IMS 

10334 

10936 

-5.5 

Utilizations 

CPU 

.5768 

.5929 

-2.7 

CH2 

.2122 

.2272 

-6.6 

CH3 

.0480 

.0481 

-0.2 

Table  2  Multiple  Class  Model  Results 
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ABSTRACT 

In  distributed  systems  with  several  independent  processors,  we  examine 
the  trade-off  between  centralized  and  decentralized  computing.  The  model  in¬ 
volves  several  symmetric  local  sites,  each  with  a  workload  and  a  processor,  and 
one  central  site  with  a  processor  to  which  portions  of  each  local  workload  can  be 
directed.  The  first  problem  we  examine  assumes  that  all  processor  speeds  are 
fixed,  and  we  seek  the  optimal  load  balancing  strategy  with  respect  to  a  user- 
oriented  objective  function.  An  additional  degree  of  freedom  is  then  introduced 
whereby  workloads  and  processor  speeds  are  optimized  jointly  subject  to  budget 
constraints.  For  each  problem,  we  examine  both  selfish  choices  on  the  part  of 
each  local  site  and  the  cooperative  choice  that  yields  the  best  overall  perfor¬ 
mance. 


1.  Introduction 

The  increasing  availability  of  computer  communication  networks,  mini¬ 
computers,  and  intelligent  terminals  has  provided  more  flexibility  to  organiza¬ 
tions  that  require  computing  facilities.  Rather  than  using  a  single  on-site  com¬ 
puter,  they  may  choose  to  direct  part  of  their  workload  to  a  remote  site  where  it 
contributes  to  the  workload  of  a  large  centralized  processor,  or  they  may 
choose  to  acquire  several  cooperating  on-site  processors.  The  vast  range  of  pos¬ 
sibilities  makes  it  difficult  to  choose  the  "best"  strategy.  In  this  paper,  we 
develop  some  analytic  tools  that  facilitate  that  choice.  Our  approach  differs 
from  previous  studies  of  the  economics  of  distributed  computing  (e.g., 
[Buhr],[Stre])  in  that  we  regard  the  distribution  of  workload,  and  the  resulting 
effect  on  system  performance,  as  playing  an  important  part  in  the  choice. 

Centralized  processing  has  the  advantage  of  greater  efficiency  since  one 
large  processor  provides  better  service  than  a  group  of  small  ones  with  the  same 
total  capacity.  Furthermore,  because  the  power  of  computing  equipment  in¬ 
creases  faster  than  linearly  with  price,  an  investment  yields  the  greatest  total 
power  when  concentrated  in  a  single  processor.  On  the  other  hand,  sending  all 
work  to  a  central  site  can  lead  to  high  communications  costs.  These  can  be 
avoided  by  distributed  processing,  where  all  work  is  processed  at  its  site  of  origi¬ 
nation. 

*This  research  was  done  while  both  authors  were  on  research  leave  at  IRIA  La- 
boria,  Rocquencourt,  France. 


-118- 


Another  factor  relating  to  the  choice  of  centralized  versus  distributed  process¬ 
ing  is  the  motivation  to  balance  the  workload  demand  across  the  available  pro¬ 
cessors. 

The  communications  costs  involved  in  centralized  processing  take  the 
form  of  either  expenditures  for  communications  equipment  or  transmission  de¬ 
lays.  We  shall  consider  costs  that  are  proportional  to  either  the  number  of  jobs 
transferred  or  to  the  input  and  output  volumes  of  the  programs  and  data 
transferred.  This  form  of  the  communication  cost  function  motivates  transfer¬ 
ring  first  those  jobs  whose  computing  requirements  are  high  relative  to  their 
volume  of  input  and  output. 

The  first  problem  considered  in  the  paper  is  that  of  workload  routing  when 
the  processing  capacities  at  the  sites  are  fixed.  For  each  local  site,  it  must  be 
determined  what  portion  of  the  load  will  be  processed  locally,  and  what  portion 
will  be  directed  to  a  central  site  shared  by  all  the  local  sites.  It  is  conceivable  to 
imagine  that  routing  decisions  could  be  made  dynamically  for  each  individual 
job.  To  make  good  dynamic  decisions,  however,  would  require  that  congestion 
information  be  exchanged  among  the  processors  very  frequently.  More  realisti¬ 
cally,  it  can  be  assumed  that  congestion  information  is  exchanged  only  periodi¬ 
cally,  and  between  these  exchanges  a  selected  portion  of  the  workload  from 
each  local  site  is  directed  to  the  shared  central  processor.  In  the  intervals 
between  these  decision  points,  the  routing  strategy  can  be  regarded  as  static. 

The  second  problem  we  consider  involves  the  allocation  of  computing 
power  among  the  sites  (subject  to  a  fixed  budget)  as  well  the  routing  of  the 
workload.  Each  site  devotes  part  of  its  budget  to  local  processing  power  and  the 
rest  is  contributed  toward  the  power  of  the  shared  central  processor.  The  work¬ 
load  routing  and  budget  allocation  decisions  cannot  be  made  independently. 

Both  our  problems,  workload  routing  for  existing  processing  facilities  and 
processor  selection  together  with  workload  routing,  can  be  treated  with  or 
without  an  assumed  cooperation  among  the  sites.  Assuming  cooperation,  deci¬ 
sions  for  each  site  are  made  with  the  goal  of  optimizing  performance  for  all  jobs. 
Alternatively,  decisions  taken  at  each  site  could  be  selfish  in  that  only  perfor¬ 
mance  for  jobs  originating  at  that  site  is  considered.  In  sections  2  and  3,  we 
consider  the  local  site  optimization  case,  and  in  section  4,  we  indicate  the 
differences  that  arise  in  the  global  optimization  case.  In  section  5,  we  present 
and  discuss  some  examples. 


2.  Local  Cost  Optimization  For  Given  Processor  Speeds 

From  the  standpoint  of  a  local  processing  station,  the  system  appears  as  il¬ 
lustrated  in  figure  1. 

Of  the  jobs  submitted  locally,  some  are  processed  by  the  local  station  and 
the  rest  are  sent  to  the  central  processor  (the  latter  is  shared  among  all  local 
stations).  Each  job  has  two  attributes:  a  length  X  (measured  in  instructions  to 
be  executed)  and  a  class  R\  both  these  attributes  are  assumedto  be  positive  real 
numbers  for  convenience.  The  decision  on  whether  to  process  a  job  locally  or 
not  is  based  purely  on  class:  there  is  a  threshold  a  such  that  a  job  is  processed 
locally  if,  and  only  if,  its  class  attribute  is  less  than  a. 
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Let  G  (r )  =  P(R  Hr )  be  the  job  class  distribution  function  and 
Fr(x)  =  P{X^x\R—r)  be  the  job  length  distribution  function  conditioned  upon 
class.  Denote  by  s(r)  the  average  length  of  a  job  of  class  r: 


oo 

s(r)  =  f  xdFr(x) 

0 

Then,  if  jobs  are  submitted  locally  at  rate  X,  the  average  amount  of  work 
(instructions  to  be  executed)  submitted  per  unit  time  is 

oo 

L-X  f  s(r)dG(r) 

0 

Of  this,  a  fraction 


J(a)=A  f  s(r)dg(r) 

0 

is  executed  locally  and  the  rest,  L-l(a),  is  sent  to  the  central  processor.  Denote 
by  L0  the  total  average  amount  of  work  sent  to  the  central  processor  by  the 
other  local  stations. 

Let  cr  and  o0  be  the  speeds  (measured  in  instructions  per  unit  time),  of  the 
local  and  central  processors  respectively.  We  assume  that  neither  processor  is 
saturated,  i.e.  that 

£(a)<  a  and  L0  +  L-l(a)<  a0  (1) 

The  first  problem  to  be  considered  concerns  the  choice  of  the  threshold  a. 
We  define  an  objective  function  D{a)  measuring  the  costs  incurred  in  choosing  a 
particular  a.  The  optimal  threshold  will  then  be  the  value  of  a  which  minimizes 
D(a).  We  wish  to  take  into  consideration  the  costs  due  to  congestion  at  the  pro¬ 
cessors  and  those  due  to  job  transfers.  The  first  will  be  represented  by  the  aver¬ 
age  numbers,  N(a)  and  N0  (a),  of  locally  submitted  jobs  at  the  local  and  central 
processors  respectively.  For  the  second,  T(a),  we  use  a  combination  of  the  aver¬ 
age  number  of  jobs  transferred,  X[l-G(a)],  and  the  average  amount  of  work 
transferred,  L—l(a),  per  unit  time.  Our  objective  function  is,  therefore, 

D(a)  -  cN (a)  +  c0N0(a)  +  T(a)  (2) 

where 

T(a)  =  61X[l-C(a)]+62[L-£(a)] 

and  c,  c0,  bi  and  b%  are  non-negative  constants.  In  order  to  deal  with  manage¬ 
able  closed-form  expressions  for  N (a)  and  N0(a),  we  shall  assume  that  jobs  ori¬ 
ginate  at  each  site  in  a  Poisson  stream,  and  that  the  scheduling  discipline  at 
both  processors  is  Processor-Sharing.  Then  we  can  write  (see,  for  example, 
[Klei]) 


N(a) 


1  -  [£(a)/cr] 


a-l (a) 


(3) 
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and 

^o(a) 


L —l (a) 

vc~[L0+L -l  (a)] 


(4) 


To  seek  a  minimum  value  for  D(a),  we  substitute  (3)  and  (4)  into  (2)  and 
examine  the  derivative: 


D'(a)=i'(a) 


c  a 


c0(^o  “  L0) 


[o-i(ot)]  [a0-L0-L  +1  (a)]2 


-  6  {\g  (a)-62Z'(a) 


(5) 


where  g(r)  =  G'(r)  is  the  job  class  density  function.  Noting  from  the  definition 
of  Z  (a),  that  Z  '(a)  =  \  s  ( a)g  (a),  we  can  rewrite  (5)  as 


D'(a)  =  Xg(a)  \s(a)[- - Cf. 

(ct-  Z  (a))z 


Co(Vo-Lq) 

( a0-L0-L+l(a ))2 


-62]-6,] 


(6) 


=  *Sr(o)  fs (a)  //(a)  -  6^ 

where  //(a)  denotes  the  term  in  the  square  brackets. 

It  is  easily  seen  that  H(a)  is  an  increasing  function  of  Z(a)  and  hence  a 
non-decreasing  function  of  a.  Suppose  that  the  average  job  length  s(r)  is  also  a 
non-decreasing  function  of  the  job  class  r.  Then  the  product  s(a)  H(a)  i3  a  non¬ 
decreasing  function  of  a  whenever  H(a)  is  non-negative.  The  position  of  the 
optimal  threshold  value  depends  on  the  behaviour  of  H (a)  at  zero  and  at  infinity, 
i.e.  (remembering  that  Z(0)=0  and  Z(°°)=Z,),  on  the  quantities 

c  __  c0(c7o ~~La)  ^ 

°  ~  (a ,-L0-Lf  ‘ 


#(-) 


c  a 

(a-L)2 


((T0  -~L0 ) 


-  b  2 


We  can  identify  two  limiting  cases: 

l.If  H( 0)^0  and  s (0)/f(0)^6 1,  then  D'(a)  is  non-negative  for  all  or.  This  implies 
that  D  (a)  is  non-decreasing  and  hence  attains  its  minimum  at  a=0.  The  optimal 
policy  in  this  case  is  to  send  all  jobs  to  the  central  processor. 

lim 

2.  If  s(°°)  where  s(°°)  = - s(r),  then  D  ’(a)  is  non-positive  for  all  a. 

7"  oo 

D(a )  is  non-increasing  and  hence  approaches  its  minimum  as  The  optimal 

policy  is  to  process  all  jobs  locally. 

If  neither  condition  1  nor  condition  2  is  satisfied,  then  there  is  an  optimal 
threshold  value  o<a*<“.  That  value  can  be  obtained  by  solving  the  equation 


s  (a)H  (a)=6  * 


-122- 


if  s(r)  is  a  continuous  function  of  r.  Otherwise,  it  is  given  by 

a*  =■  suj>[ol\  s  (a)H (a)<b 


and  can  be  found  numerically  by  a  binary  search  technique.  Note  that,  once  the 
inequality  s (a)H (a)£6 1  is  satisfied  for  some  o',  it  is  satisfied  for  all  a£a'.  One 
does  not  have  to  worry,  therefore,  about  non-global  optima. 

The  problem  is  simplified  considerably  if  b^o.  Then  the  optimization  can 
be  performed  with  respect  to  the  variable  L-l(a),  rather  than  with  respect  to  a. 
Moreover,  no  assumptions  regarding  the  behaviour  of  s(r)  are  necessary.  When 
the  optimum  is  not  i=0  or  l-L,  it  is  the  unique  positive  solution  l*  of  the  equa¬ 
tion 


c  a _ co  ((7o~L0)  _ 

(a-02  ( v0-L0-L+l)z  ~  2 

If  b2  is  also  equal  to  zero  (no  transfer  costs  at  all),  then  l*  is  given  by 

_  v^/c0(aa-Lo)  -  (a0-L0-L)'Sco 

VCo (Vo-La)  +  Vcct 

For  the  last  case,  and  when  c=c0,  it  can  be  shown  that  under  optimal  transfer¬ 
ring  policy,  the  faster  processor  is  always  more  heavily  utilized.  In  other  words, 
if 


(ct0-L0)>(j 

then 

[(£-(•  )/K-£„)]  >  (l’/a) 

and  vice  versa.  An  analogous  result  holds  for  maximizing  throughput  in  queue¬ 
ing  networks  [Buz]. 

It  may  be  that  the  extreme  values  of  a  are  not  feasible:  For  example,  if 
L> cr,  the  local  processor  cannot  cope  with  all  the  local  work  without  saturating 
and  a  must  satisfy  the  constraint  a<amax,  where  l  (a-m**)  =  cr.  Clearly,  condition 
2  cannot  hold  in  that  case.  Similarly,  if  Lo+L>a0l  a  must  satisfy  a  constraint  of 
the  type  a>amin  and  condition  1  cannot  hold.  From  the  inequalities  (l)  it  follows 
that  crmin<o(max  (i-e-  there  exist  feasible  values  for  a)  if,  and  only  if,  a0  +  a>L  +L0. 


3.  Local  Cost  Optimization  With  Choice  Of  Processor  Speeds 

So  far,  the  values  of  a  and  <r0  have  been  considered  as  fixed;  the  threshold 
optimization  has  been  performed  for  an  existing  system.  Suppose  now  that  the 
system  is  in  a  planning,  or  modification  stage.  The  manager  of  the  local  site  has 
a  sum  of  money,  M,  which  he  is  free  to  either  invest  locally  or  contribute  to  the 
central  installation.  The  speeds  of  the  two  processors  will  then  depend  on  the 
way  the  money  is  spent.  This  gives  rise  to  a  two-dimensional  optimization  prob¬ 
lem. 
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Assume  that  the  speed  of  a  processor  is  proportional  to  a  certain  power  of 
the  money  invested  in  it.  Thus,  if  the  local  station  manager  spends  an  amount  m 
on  the  local  processor  and  contributes  the  rest  of  his  funds,  M—m,  to  the  central 
installation,  and  if  an  amount  M0  is  invested  at  the  central  processor  by  the 
other  local  stations,  then  the  speeds  of  the  two  processors  will  be 

cr(m)  =  am7;  cr0(m)  =  a(M0+M -m)7  ,  a>0,  7^1  (7) 

(The  economy  of  scale  in  purchasing  computer  power  is  reflected  in  7  being 
greater  than  one.  According  to  "Grosch's  law",  7«2  [Sheu-].)  Equations  (2),  (3), 
(4)  and  (7)  now  define  a  cost  function  D  (a,m)  depending  on  two  parameters;  the 
problem  is  to  find  a  pair  (a*m*)  which  minimizes  D(a,m)  subject  to  the  con¬ 
straints  (1),  which  become 

l(a)<am7  ;  L0+L  -1(a)  <a  (M0+M-m  )7  (8) 

Let  us  examine  first  the  set  F  of  feasible  pairs  (l,m)  defined  by  the  inequal¬ 
ities  (8).  That  set  is  non-empty  if,  and  only  if, 

L0+L  <  a(M0+M)7 

(investing  all  the  funds  at  the  central  processor  should  enable  it  to  cope  with  all 
the  work).  When  not  empty,  F  may  consist  of  one  contiguous  region  or  two  dis¬ 
joint  ones.  Two  typical  cases  are  illustrated  in  figure  2.  The  lines 


l  =am7  and  l=L0+L—a(M0+M -m)7 

cross  if 

L0+L  M0+M 

—  i  a(—2-r 

i.e.  if  half  of  the  total  funds  cannot  buy  a  sufficiently  fast  processor  to  cope  with 
half  of  the  total  work.  It  is  also  possible  that  the  lines  cross,  but  there  is  no 
upper  feasible  region;  This  occurs  when 

L  +L0  Z  aM7  +  aM7 

All  these  statements  follow  directly  from  (8).  There  are  thus  four  distinct  possi¬ 
bilities: 


M  +M 

0<Lo+L  <2a  ( — — )7  :  F  is  of  type  (a),  figure  2. 


(0 


M  +M 

2a( — — )7  <LQ+L<a(MZ+M7)  :  F  is  of  type  (b),  figure  2. 


<ii) 


(iii) 


a (MJ+M7)  ^L0+L<  a (M0+M)7  :  F  is  of  type(b), lower  region  only. 


E 
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a  (M0  +M  )y  ^ L0+L  :  F  is  empty.  (iv) 

To  find  the  optimal  pair  (a* m*)  one  could  proceed  as  follows.  Determine, 
for  each  a,  the  corresponding  optimal  value  of  m;  this  gives  a  curve  m  —  <p(a)  (or 
m=Tfs(l )  in  the  mxl  plane).  Then  find  the  value  a*  which  minimizes  the  function 
D(a,  97(a)).  The  pair  (a*  <p(a*))  will  be  the  desired  optimal  allocation  of  money 
and  load. 

The  curve  m  =  p(a)  is  independent  of  the  transfer  costs  because  the  latter 
are  constant  with  respect  to  m.  Take  the  partial  derivative 

dP(a,m)  _  L  (ot)cr'(m)  _  ^  [L-l(a)]  cr0'(m) 

dm  [a (m)-i(a)]2  0  [a0(m)-L0-L  +l(a)]2 

where  a(m)  and  cr0(m)  are  given  by  (7).  It  is  not  difficult  to  see  that  the  right- 
hand  side  of  (9)  is  an  increasing  function  of  m  varying  between  —  °°  and  °°  on  the 
interval 


[K2I]  1/7  <  m  <Mc+M-  t(a)]  1/r 

a  a 

Denote  by  ^„(a)  the  single  root  of  the  equation 

dP(a,7n)  _ 
dm 


on  that  interval.  The  optimal  value  of  m  for  a  fixed  (and  feasible)  value  of  a  is 
given  by 

m  =  min(i^0(a),A/)  (10) 


The  task  of  minimizing  P  (a,  97(a))  with  respect  to  a  is  much  more  difficult. 
There  may  be  one  or  more  non-global  minima  (at  most  one  per  local  maximum 
hi  g(r)),  which  have  to  be  examined.  Moreover,  if  F  is  of  type  (ii),  the  minimiza¬ 
tion  has  to  be  performed  separately  for  the  two  sub-regions  and  the  results  com¬ 
pared.  It  seems  certain  that,  in  a  general  case,  one  would  have  to  apply  a 
numerical  procedure  involving  a  search. 


Some  analytical  results  can  be  obtained  in  the  special  case  of  7=1.  Substi¬ 
tuting  (7)  into  (9)  and  solving  for  m  we  obtain 


<P  o(«)  =  —  [*(«)  + 

a 


t$Vct(a) _ 

Vcl(a)  +  ^/c0(L  -1(a)) 


] 


(11) 


where  6  =  a (M0+M)-L0-L.  The  right  hand  side  of  ( 11)  is  an  increasing  function 
of  a  and  therefore  there  is  at  most  one  point  at  which  it  crosses  the  line  m-M. 
Along  the  curve  m=9?0(a),  the  derivative  of  the  cost  function  is  given  by 


dP(a,  <p0(a)) 
d  a 


Xg 


5-y 


-  f>2]-f>i!, 


(12) 
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where  y=a<p0(a)-l(a).  It  follows  from  (11)  that  y  increases  with  1(a):  hence  the 
term  in  square  brackets  in  the  right-hand  side  of  (12)  is  a  non-increasing  func¬ 
tion  of  a.  In  particular,  that  term  is  non-positive  when 

(1— rfer).  (13) 

2  y/w  +4 


where 

™=(62<5+  c0-c)/  y/cc^. 


Thus,  for  the  optimal  pair  (a*  m*),  either 


K«')<i(i—nr t>* 

2  wwz+4 


or  m*  =  M. 


In  the  special  case  of  6^0,  we  can  draw  a  stronger  conclusion.  If  7=1  and 
6 1=0,  then  the  cost  function  cannot  have  a  minimum  along  the  curve  ra  =  p0(a) 
on  the  open  interval  0<7n<Af;  the  optimal  allocation  of  funds  is,  in  that  case, 
either  m  —  0  or  m -M. 


We  conjecture  that,  since  it  becomes  less  and  less  advantageous  to  split 
one’s  investment  as  y  increases,  the  above  result  is  true  for  any  7^1. 

If,  on  the  other  hand,  t>i>0,  then  it  is  possible  for  the  optimal  pair  (m*  a*) 
to  be  in  the  interior  of  the  feasible  region  even  when  7=1.  This  will  be  illustrated 
later  by  an  example. 


4.  Global  Cost  Optimization 

In  the  previous  section,  we  treated  the  case  in  which  each  site  bases  its 
strategy  decisions  on  the  goal  of  attaining  the  best  performance  for  the  jobs  ori¬ 
ginating  at  that  site.  Here,  workload  routing  and  placement  of  processing  power 
will  be  aimed  at  a  common  goal:  the  best  performance  for  all  jobs  regardless  of 
origin. 

Again,  consider  first  the  case  in  which  processor  speeds  are  fixed  and  each 
of  fc  sites  processes  some  of  its  load  locally  while  sending  the  rest  to  the  central 
shared  processor.  Extending  the  notation  of  Chapter  2  in  an  obvious  way,  we  use 
a  vector  of  thresholds  d=(oci,  a2,  0*3,. ...  a*.)  to  control  the  job  routing.  For  fixed 
(at,  a2,...,  aj-i,  ay+j,...,  a*),  we  can  determine  the  best  value  for  aj  with  respect  to 
the  entire  population  of  jobs.  We  wish  to  minimize  the  following  objective  func¬ 
tion  with  respect  to  0^: 

£(*)  =  £  [ciA^aJ  +  7\(at)]  +  c0N0(& )  (14) 

i=  1 

where  Ni(ai )  is  the  average  number  of  jobs  at  processor  i  (see  expression  (3)), 
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?\(ai)  —  ^  +  &2i  [A“^i(ai)] 


represents  the  transfer  costs  for  site  i  and 


Y,lU-k(ai)] 

N0(a)  =  — i-^-je - 


is  the  total  average  number  of  jobs  at  the  central  processor.  All  of  cit  c0,  bu  and 
bzi  are  non-negative  constants. 

Because  only  the  jth  term  of  the  first  sum  is  dependent  on  ay,  this  expres¬ 
sion  for  D  (d)  corresponds  directly  to  that  for  D(a)  in  section  2.  This  can  be 
seen  by  writing  equation  (14)  as 


BW-B+  .,*,(«,)  + 


where 


and 


B  =  s  +  A(«i)] 

i*; 


L0  =  E  fo-tfo,)] 


(15) 


Both  5  and  L0  are  independent  of  ay.  Moreover,  the  last  term  in  the  right-hand 
side  of  (15)  differs  from  N0  in  (2)  only  by  the  replacements  of  L  by  L0+Lj  and  L0 
by  zero.  Thus,  the  results  of  section  2  carry  over  to  the  present  problem.  In 
particular,  the  position  of  the  optimal  threshold  for  site  j  depends  on  the  quanti¬ 
ties 


and 


as  follows: 


n>  r  \  CJ  co°o 

=  ,„_r_ 


v.uo 


Lo-hY 


-  b 


2  i 


Rji00) 


{a i-L'-Ltf 


If  Ftj{ 0)^0  and  sy(0) /7y(0)^&  iy,  then  the  optimal  threshold  is  ay= 0.  If 
si(  OO  )H,(  OO  )< 6  iy ,  then  the  optimal  threshold  is  ay=°°.  If  6iy  =  &2y=0,  and  the 
optimal  workload  is  neither  zero  nor  Ly,  then  it  is  given  by 


^  _  cry>/ c0 o’©  (cTo  y/cj cry 


^  = 


VCqOo  +  VCyO-y 


The  global  optimization  problem  involves  fc  interrelated  decisions,  one  for 
each  local  processor.  This  problem  can  be  formulated  conveniently  as  a 
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dynamic  programming  problem.  At  stage  j,  local  processor  j  must  decide  how 
much  of  its  load  to  process  locally  in  light  of  previous  decisions  at  processors  1 
to  j—  1,  and  assuming  that  the  later  decisions  at  processors  j+ 1  to  k  will  be 
optimal  within  the  limitations  imposed  by  prior  decisions. 

Define 

AJ  =  ^X 
i=l 

At  processor  j,  will  be  chosen  to  minimize  the  function 


Dj(Aj,  ay,  aj+ 1,  ....  ak)  -  CjNj(aj)  +  7y(ay)  +  D*j+i(Aj+LJ-lj(ai))  (16) 

where 


Dj+l*(Z)  = 


_ min _ 

(oty  +  l,  ....  (Xk  ) 


Dj(Z,  ay+1,...,  ak) 


is  the  least  total  cost  among  processors  j+1  to  k  and  the  central  processor 
given  load  Z  on  the  central  processor  from  nodes  1  to  j  alone. 

(We  define 


The  algorithm  of  display  1  determines  the  optimal  {ay*}  values.  (The  variables 
Aj  and  ay  must  be  made  discrete  in  implementing  the  algorithm.)  The  algorithm 
determines  successively  (in  tabular  form)  the  functions  Dk  *{Ak), 

-Ojt-i*(Afc-i) . Dx*{Ax)  and  a k*(Ak),  a*-!*^*-!),  •  •  •  at*(Ai).  Because  Z>i(0,  c*y) 

is  precisely  the  objective  function,  jDi*(0)  is  the  optimal  value  of  the  objective 
function  and  aj*(0)  is  the  optimal  load  to  process  at  processor  1.  The  other 
loads  are  determined  in  turn  as  ay*  (Ay*)  where 
Aj*  =  Ay_ i*  +  Ly_i— iy_i(ay_i* (Ay_i* ))  is  the  load  on  the  central  processors  from 
sources  1  to  j  —  1  under  their  optimal  decisions.  (LetAi*=0.) 

Consider  next  the  case  in  which  an  amount  of  money  M  is  available  to  pur¬ 
chase  processing  power  at  the  k  local  processors  and  the  central  processor.  For 

amount  of  money  m,  a  processor  with  speed  cr(m)  =  am7  can  be  obtained.  The 

k 

problem  is  to  determine  the  fund  allocations  (mi,m2j...1mjt)  where  J]  and 

i  =  \ 

the  workload  thresholds  (at,  a^-.-.a*)  in  order  to  achieve  the  best  performance 
on  average  for  all  jobs. 

Again,  we  start  by  assuming  fixed  values  for  parameters  (ai,7ni),  l^i^k  at 
all  sites  except  j.  We  wish  to  pick  (ay.my)  to  minimize  the  objective  function: 

k  X 

Dfarfi)  =  XI  [^i(ai.77k)  +  7’t(ai)]  +  - - 

i=1  o’o(tA)  ~  X  ((Li-hM) 

»= l 


Afc  +  1*  (Ak+l)  — 


lk  + 1 


(T0 -A 


Jb  +  1 
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Once  again,  only  the  jth  term  of  the  first  sum  is  affected  by  the  choice  of  my  and 
aj,  and  again,  by  the  proper  change  of  variables  independent  of  (ctj.wij-),  we  can 
see  that  this  objective  function  has  the  same  form  as  the  corresponding  one  in 
the  previous  section. 

From  the  previous  section,  we  know  the  difficulty  of  obtaining  explicit 
expressions  for  my*  and  ay*.  However,  if  they  can  be  obtained  numerically,  then 
we  may  again  use  dynamic  programming  to  treat  the  interaction  among  the 
decisions  at  various  sites.  Display  2  gives  the  algorithm,  which  operates  in  a 
similar  manner  as  that  in  Display  1. 


5.  An  Example  of  Local  Cost  Optimization 

Here  we  shall  demonstrate  that  the  problem  of  finding  an  optimal  load  and 
money  allocation  with  respect  to  a  local  cost  function  is  in  general,  non¬ 

trivial.  That  is,  the  solution  may  be  in  the  interior  of  the  feasible  region,  as  well 
as  at  one  of  the  extremes.  The  same  will  be  true,  of  course,  for  an  individual  site 
optimization  with  respect  to  a  global  cost  function. 

In  the  example  that  we  have  chosen,  the  job  class  distribution  and  density 
functions  are  giben  by 


C{r)  =  l-[l/(l+r)2]  ;  g(r)  =  2/(1  +r)3 
and  the  average  length  of  a  class  r  job  is 

s(r)  =  r 


For  a  given  threshold  a,  the  average  amount  of  work  executed  locally  is 

f(a)  =  Aa2/(l+a)2, 

while  the  total  average  load  submitted  locally  per  unit  time  is  L  =£(«>)= A.  The 
relation  between  a  and  l  can  be  inverted  explicitly:  The  threshold  a  which 
results  in  an  average  load  l  being  executed  locally  is 

a(l)  =  VT/(Va  -  y/T)  =  VT /{yfL  —  VT) 

The  cost  function  (2)  can  now  be  expressed  in  terms  of  l  and  m  (see  eqs. 
(3)  and  (4)): 


cl  c0(L—l) 

u(m  )-l  cr0(m.)-(L0+L-l) 


+  b  i(L  +l-2rJlL  )  +  bz(L-l ) 


In  expressions  (7)  we  shall  take  a  =7=1,  so  that  cr(m )=m  and  a0(m)  =  M0+M — m. 
According  to  (10)  and  (11),  the  optimal  money  allocation  for  a  given  load  pro¬ 
cessed  locally  is  given  by 


m  =  Tp(l )  =  l  +y  if  l  +j  and  M  otherwise 
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where  „ 

y  =  6'/cl/[Jcl  +  yJc0{L-l)]  and  5  =  M0+M-L0-L. 


Figure  3  shows,  for  a  particular  set  of  parameter  values,  the  optimal  curve 
m=V'(0.  the  cost  function  D(l,iJ/(l))  along  that  curve  and  the  optimal  pair 
(L*,m*).  (The  values  of  D(l,Tp(l))  have  been  plotted  as  distances  from  the  m  - 
axis).  In  this  case,  the  best  policy  is  to  split  both  the  investment  and  the  load. 
Note  that  here  we  do  not  observe  the  decreasing  portion  of  the  cost  function 
suggested  by  (13);  this  is  because  for  l-(L/2)(l-w/\fw*+4)  we  have  L+y>M. 

Different  parameter  values  may  lead  to  significantly  different  optimal  allo¬ 
cations.  The  following  are  some  examples  (parameters  that  are  not  mentioned 
have  the  same  values  as  in  figure  3): 

1)  c=6,  c0  =  l,  6 1=4:  £*=m*  =  0  (best  policy  is  to  send  all  jobs  to  the  central  pro¬ 
cessor  and  invest  all  funds  there) 

2)  c  =  l,  co  =  10,  bt=4:  0 <1*<L,  m*  -M  (invest  all  funds  locally,  but  send  some 
jobs  to  the  central  processor). 

3)  c=l,  c0  =  10,  6 1=16:  l*  -L,  m*  =M  (process  all  jobs,  and  invest  all  fund3, 
locally). 

Why  is  it  that,  when  6i=0,  the  optimal  allocation  is  always  extreme 
(m*  =  0  or  whereas  if  6i>0  it  can  be  anywhere?  In  the  former  case,  all 

costs  (queueing  and  transfer)  depend  on  the  load  L  only,  and  not  on  the  number 
of  jobs  transferred.  Under  those  circumstances  it  turns  out  that  if  it  is  advanta¬ 
geous  to  shift  some  load  and  funds  from  the  central  to  the  local  processor,  it  is 
advantageous  to  shift  them  all.  If,  on  the  other  hand,  6i>0  and  the  distribution 
of  job  lengths  is  highly  scewed  towards  zero  (  as  in  our  example),  then  a  small 
change  in  the  load  transferred  may  mean  a  large  change  in  the  number  of  jobs 
transferred  and  hence  a  big  difference  in  the  costs  incurred.  In  the  example  of 
figure  3,  a  small  investment  at  the  local  processor  enables  it  to  process  a  small 
load  locally.  However,  that  small  load  is  made  up  of  a  large  number  of  very 
short  jobs;  thus  a  significant  saving  in  transfer  costs  is  achieved. 


6.  Conclusions 

In  summary,  we  have  found  that  these  practically  important  and  conceptu¬ 
ally  simple  problems  have  complex  solutions.  Let  U3  summarize  the  results  in 
order  of  increasing  generality  and  complexity. 

Fixed  processor  speeds 

CASE  I:  No  transfer  costs  (61=62=0) 

If 

c  ^  tr(o-o-Lo) 
c0-  (a0-L„-L)z 


then  process  all  jobs  centrally. 
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FIGURE  3. 
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If 


then  process  ail  jobs  locally. 


_c_  g  {v~L)Z 

c0  ct(c r0~L0) 


Otherwise,  process  load  l*  locally  and  L-L*  centrally  where 
l*  =  CT^Co(cr°~Lo)  ~  (cr0— L0— L )Vc o 
y/co(cro~I'o)  +  ^ 

CASE  II:  Transfer  cost  proportional  to  load  transferred  (6j=0) 

If 

C  Co(&0~  Lq) 


a  ( <t0-L0-L ) 


-1.  -M2  ^  hz 


then  process  all  jobs  centredly. 
If 


c  O 


{<t-L)z  ( v0-Lo) 


£  b. 


then  process  all  jobs  locally. 


Otherwise,  process  load  l*  locally  and  L—l*  centrally  where  l*  satisfies 

co  c0(o0-L0) 

2  ~  °2 


(o-l)2  ( o0-L0-L+l ) 

CASE  HI:  Unrestricted  transfer  costs  (6  i>0  and  6  2^0) 

If 

/nW  C  Co((T0~^Jo)  ,  -l  , 

s(0)[—  "  7 - } — FT 2  ~  b 2]  ^  6i 

(T  (o0-L0-L  )2 

then  process  all  jobs  centrally. 

If 


c  o 


-62S 


( o-L)2  (o-q-Lo)  2  s(°°) 

then  process  all  jobs  locally. 

Otherwise,  process  load  Z(a*)  locally  and  L-l(a*)  centrally  where  a* 
satisfies 


c  o 


c0(o0-L0) 

-  o  2  = 


(cr-l(a*))s  (a0-L.-L+l(<x»)f  2  s{a*) 


N on- fixed,  processor  speeds 

When  processor  speeds  as  well  as  loads  can  be  chosen,  the  amount  of 
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money  available  and  the  total  workload  determine  the  shape  of  the  region  of 
feasible  choices  in  the  two-dimensional  plane  representing  the  choices  of  money 
spent  locally  and  load  processed  locally.  If  processor  speeds  Eire  linear  func¬ 
tions  of  money  spent  (7  =  l),  then  the  feasible  choices  lie  in  a  connected  region. 


CASE  L  Transfer  costs  proportional  to  load  transferred  (7=  1  and  6^0) 

The  optimal  money  allocation  is  one  of  the  two  extremes:  all  locally  or  all  cen¬ 
trally. 


CASE  II:  Unrestricted  transfer  costs  (7=1  and  >  0) 

Either  all  money  should  be  allocated  locally  or  only  some  load  less  than 


2  \/w2+  4 


where 


b  2<5  +  c0  — c 

w  =  — r — 

V  cco 

should  be  processed  locally. 


It  requires  some  care  to  construct  an  example  where  the  optimal  alloca¬ 
tion  of  money  is  not  one  of  all  locally  or  all  centrally.  Hence,  there  is  reason  to 
believe  that,  empirically,  one  of  the  extreme  money  allocations  would  often  be 
close  to  optimal. 

When  processor  speed  increases  faster  than  linearly  with  the  money 
invested  (7>1),  there  is  still  less  incentive  to  split  the  money  allocation.  It  would 
seem  more  likely  in  this  case  that  the  money  allocation  should  be  one  of  the  two 
extremes. 


The  problem  of  minimizing  costs  over  all  the  sites  simultaneously  can  be 
formulated  as  a  dynamic  programming  problem.  The  form  of  the  problem  at 
each  stage  is  then  identical  to  that  faced  in  individual  site  optimization.  Thus, 
the  assertions  above  remain  relevant. 

The  choice  of  representation  of  transfer  costs  appears  to  be  critical  in  the 
family  of  models  we  have  treated.  Both  the  analysis  and  the  results  are  affected 
substantially  by  the  assumption  that  6  1  or  6  2  or  both  are  zero. 

We  have  assumed  processor-sharing  as  the  scheduling  discipline  at  all  pro¬ 
cessors.  Attempting  to  treat  the  first-come-first-served  discipline  in  the  same 
way  increases  the  complexity  of  the  problem  by  involving  the  coefficient  of  vari¬ 
ation  of  the  service  time  distributions  in  the  objective  function.  The  analysis 
becomes  very  difficult  because  the  coefficients  of  variation  of  the  service  time 
distributions  at  both  the  local  and  central  processor  depend  on  what  proportion 
of  the  load  is  transferred  from  one  to  the  other. 
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Display  1 


For  processors  j =k  to  1, 

For  all  Ay.  O^Ay  £  £  L< 

<=i 

For  all  ay. 

Evaluate  Z?y(Ay,  ay)  =  _ATy(ay)  +  7y(ay)  +  Dy+1*(Ay+Z/y-£y(ay)) 
End 

ay*(Ay)  satisfies  Dj*{Aj)  =  ZJy(Ay,iy(ay*(Ay))) 

End 
End 
A  i=0 

For  processors  j '  —  1  to  k 

<*j*  *-  <*j*(Aj) 

Aj+ 1  +-  Aj+Lj-lj{aj*) 

End 

Dynamic  Programming  Algorithm  For  Fixed  Processor  Speeds  Case 


Display  2 


For  processors  j  =  k  to  1, 

For  all  Ay.  O^Ay^  £  Lt 

t=i 

For  all/y,  0^/y^A/ 

For  all  ay, 

For  all  my,  Oiimy^/y 
Evaluate 


End 

End 


Dj  (Ay./y.my,  ay)=//y(my,  ay)+7y(ay) 
+Dy  + 1  *  (Ay  +Lj—lj (ay  ),/y“77Ty  ) 


Dy«(Ayi/y)=  By (Ay,/y,my,  ay) 

ay*(Ay,/y)  and  my  •  (Ay, Ij ) 

satisfy  Dy  *(Ay,/y)=Dy(Ay,/yJ  my*  (Ay./y),  ay*(Ay,/y)) 

End 

End 

End 

A  i=0-,I  i=M 


For  processors  j  =  1  to  fc 

ay* 

my  * 

T^J*(Aj,I y) 

-^j+l 

<-  Ay  +  Lj  ~  iy(a y 

7i+l 

<-  /y  —  m 

End 

Dynamic  Programming  Formulation  For  Money  Allocation  Case 
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[Proceedings  AFIPS  Fall  Joint  Computer  Conference, 
v.  41,  December  1972] 

*  CSRG-20  A  STUDY  OF  LANGUAGE  DIRECTED  COMPUTER  DESIGN 

David  B.  Wortman,  December  1972 

[Ph.D.  Thesis,  Computer  Science  Department, 

Stanford  University,  1972] 

CSRG-21  AN  APL  TERMINAL  APPROACH  TO  COMPUTER  MAPPING 
R.  Kvaternik,  December  1972 
[M.Sc.  Thesis,  DCS,  1972] 

*  CSRG-22  AN  IMPLEMENTATION  LANGUAGE  FOR  MINICOMPUTERS 

G.G.  Kalmar,  January  1973 
[M.Sc.  Thesis,  DCS,  1972] 

CSRG-23  COMPILER  STRUCTURE 

W.M.  McKeeman,  January  1973 

[Proceedings  of  the  USA-Japan  Computer  Conference,  1972] 
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*  CSRG-24  AN  ANNOTATED  BIBLIOGRAPHY  ON  COMPUTER  PROGRAM 

ENGINEERING 

J.D.  Gannon  (ed.),  March  1973 

CSRG-25  THE  INVESTIGATION  OF  SERVICE  TIME  DISTRIBUTIONS 
Eleanor  A.  Lester,  April  1973 
[M.Sc.  Thesis,  DCS,  1973] 

*  CSRG-26  PSYCHOLOGICAL  COMPLEXITY  OF  COMPUTER  PROGRAMS: 

AN  INITIAL  EXPERIMENT 
Larry  Weissman,  August  1973 

*  CSRG-27  STRUCTURED  SUBSETS  OF  THE  PL/I  LANGUAGE 

Richard  C.  Holt  and  David  B.  Wortman,  October  1973 

*  CSRG-28  ON  REDUCED  MATRIX  REPRESENTATION  OF  LR(k) 

PARSER  TABLES 

Marc  Louis  Joliat,  October  1973 

[Ph.D.  Thesis,  EE  1973] 

*  CSRG-29  A  STUDENT  PROJECT  FOR  AN  OPERATING  SYSTEMS  COURSE 

B.  Czarnik  and  D.  Tsichritzis  (eds.).  November  1973 

*  CSRG-30  A  PSEUDO-MACHINE  FOR  CODE  GENERATION 

Henry  John  Pasko,  December  1973 
[M.Sc.  Thesis,  DCS  1973] 

*  CSRG-31  AN  ANNOTAED  BIBLIOGRAPHY  ON  COMPUTER  PROGRAM  ENGINEERING 

J.D.  Gannon  (ed.),  Second  Edition,  March  1974 

*  CSRG-32  SCHEDULING  MULTIPLE  RESOURCE  COMPUTER  SYSTEMS 

E. D.  Lazowska,  May  1974 
[M.Sc.  Thesis,  DCS,  1974] 

*  CSRG-33  AN  EDUCATIONAL  DATA  BASE  MANAGEMENT  SYSTEM 

F.  Lochovsky  and  D.  Tsichritzis,  May  1974 
[INFOR,  14  (3),  pp. 270-278,  1976] 

*  CSRG-34  ALLOCATING  STORAGE  IN  HIERARCHICAL  DATA  BASES 

P.  Bernstein  and  D.  Tsichritzis,  May  1974 
[Information  Systems  Journal,  v.  1,  pp.  133-140] 

*  CSRG-35  ON  IMPLEMENTATION  OF  RELATIONS 

D.  Tsichritzis,  May  1974 

*  CSRG-36  SIX  PL/I  COMPILERS 

D.B.  Wortman,  P.J.  Khaiat,  and  D.M.  Lasker,  August  1974 
[Software  Practice  and  Experience,  v.6,  n.3, 

July-Sept.  1976] 

*  CSRG-37  A  METHODOLOGY  FOR  STUDYING  THE  PSYCHOLOGICAL  COMPLEXITY 

OF  COMPUTER  PROGRAMS 
Laurence  M.  Weissman,  August  1974 
[Ph.D.  Thesis,  DCS,  1974] 
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*  CSRG-38  AN  INVESTIGATION  OF  A  NEW  METHOD  OF  CONSTRUCTING  SOFTWARE 

David  M.  Lasker,  September  1974 
[M.Sc.  Thesis,  DCS,  1974] 

CSRG-39  AN  ALGEBRAIC  MODEL  FOR  STRING  PATTERNS 
Glenn  F.  Stewart,  September  1974 
[M.Sc.  Thesis,  DCS,  1974] 

*  CSRG-40  EDUCATIONAL  DATA  BASE  SYSTEM  USER’S  MANUAL 

J.  KlebanofT,  F.  Lochovsky,  A.  Rozitis,  and 

D.  Tsichritzis,  September  1974 

*  CSRG-41  NOTES  FROM  A  WORKSHOP  ON  THE  ATTAINMENT  OF 

RELIABLE  SOFTWARE 

David  B.  Wortman  (ed.),  September  1974 

*  CSRG-42  THE  PROJECT  SUE  SYSTEM  LANGUAGE  REFERENCE  MANUAL 

B.L.  Clark  and  F.J.B.  Ham,  September  1974 

*  CSRG-43  A  DATA  BASE  PROCESSOR 

E. A.  Ozkarahan,  S.A.  Schuster  and  K.C.  Smith, 

November  1974  [Proceedings  National  Computer 
Conference  1975,  v.44,  pp. 379-388] 

*  CSRG-44  MATCHING  PROGRAM  AND  DATA  REPRESENTATION  TO  A 

COMPUTING  ENVIRONMENT 
Eric  C.R.  Hehner,  Novemver  1974 
[Ph.D.  Thesis,  DCS.  1974] 

See  Computer,  Vol.9,  No. 9,  August  1976,  pp. 65-70. 

*  CSRG-45  THREE  APPROACHES  TO  RELIABLE  SOFTWARE;  LANGUAGE  DESIGN, 

DYADIC  SPECIFICATIONS,  COMPLEMENTARY  SEMANTICS 
J.E.  Donahue,  J.D.  Gannon,  J.V.  Guttag  and 
J.J.  Horning,  December  1974 

CSRG-46  THE  SYNTHESIS  OF  OPTIMAL  DECISION  TREES  FROM 
DECISION  TABLES 

Helmut  Schumacher,  December  1974 

[M.Sc.  Thesis,  DCS,  1974;  CACM,  v.19,  n.6,  June  1976] 

*  CSRG-47  LANGUAGE  DESIGN  TO  ENHANCE  PROGRAMMING  RELIABILITY 

John  D.  Gannon,  January  1975 
[Ph.D.  Thesis,  DCS,  1975] 

*  CSRG-48  DETERMINISTIC  LEFT  TO  RIGHT  PARSING 

Christopher  J.M.  Turnbull,  January  1975 
[Ph.D.  Thesis,  EE,  1974] 

*  CSRG-49  A  NETWORK  FRAMEWORK  FOR  RELATIONAL  IMPLEMENTATION 

D.  Tsichritzis,  February  1975  [in  Data  Base  Description, 

Dongue  and  Nijssen  (eds.),  North  Holland  Publishing  Co.] 
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*  CSRG-50  A  UNIFIED  APPROACH  TO  FUNCTIONAL  DEPENDENCIES 

AND  RELATIONS 

P.A.  Bernstein,  J.R.  Swenson  and  D.C.  Tsichritzis 
February  1975  [Proceedings  of  the  ACM  SIGMOD 
Conference,  1975] 

*  CSRG-51  ZETA:  A  PROTOTYPE  RELATIONAL  DATA  BASE  MANAGEMENT  SYSTEM 

M.  Brodie  (ed).  February  1975  [Proceedings  Pacific  ACM 
Conference,  1975] 

CSRG-52  AUTOMATIC  GENERATION  OF  SYNTAX-REPAIRING  AND 
PARAGRAPHING  PARSERS 
David  T.  Barnard,  March  1975 
[M.Sc.  Thesis,  DCS,  1975] 

*  CSRG-53  QUERY  EXECUTION  AND  INDEX  SELECTION  FOR  RELATIONAL 

DATA  BASES 

J.H.  Gilles  Farley  and  Stewart  A.  Schuster,  March  1975 

CSRG-54  AN  ANNOTATED  BIBLIOGRAPHY  ON  COMPUTER  PROGRAM 
ENGINEERING 

J.V.  Guttag  (ed.),  Third  Edition,  April  1975 

CSRG-55  STRUCTURED  SUBSETS  OF  THE  PL/1  LANGUAGE 

Richard  C.  Holt  and  David  B.  Wortman,  May  1975 

*  CSRG-56  FEATURES  OF  A  CONCEPTUAL  SCHEMA 

D.  Tsichritzis,  June  1975  [Proceedings  Very  Large 
Data  Base  Conference,  1975] 

*  CSRG-57  MERLIN:  TOWARDS  AN  IDEAL  PROGRAMMING  LANGUAGE 

Eric  C.R.  Hehner,  July  1975 

see  Acta  Informatica  Col.  10,  No. 3,  pp. 229-243,  1978 

CSRG-58  ON  THE  SEMANTICS  OF  THE  RELATIONAL  DATA  MODEL 
Hans  Albrecht  Schmid  and  J.  Richard  Swenson, 

July  1975  [Proceedings  of  the  ACM  SIGMOD  Conference,  1975] 

*  CSRG-59  THE  SPECIFICATION  AND  APPLICATION  TO  PROGRAMMING 

OF  ABSTRACT  DATA  TYPES 
John  V.  Guttag,  September  1975 
[Ph.D.  Thesis,  DCS,  1975] 

*  CSRG-60  NORMALIZATION  AND  FUNCTIONAL  DEPENDENCIES  IN  THE 

RELATIONAL  DATA  BASE  MODEL 
Phillip  Alan  Bernstein,  October  1975 
[Ph.D.  Thesis,  DCS,  1975] 

*  CSRG-61  LSL:  A  LINK  AND  SELECTION  LANGUAGE 

D.  Tsichritzis,  November  1975  [Proceedings  ACM 
SIGMOD  Conference,  1976] 
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*  CSRG-62  COMPLEMENTARY  DEFINITIONS  OF  PROGRAMMING  LANGUAGE 

SEMANTICS 

James  E.  Donahue,  November  1975 
[Ph.D.  Thesis,  DCS,  1975] 

CSRG-63  AN  EXPERIMENTAL  EVALUATION  OF  CHESS  PLAYING  HEURISTICS 
Lazio  Sugar,  December  1975 
[M.Sc.  Thesis,  DCS,  1975] 

CSRG-64  A  VIRTUAL  MEMORY  SYSTEM  FOR  A  RELATIONAL  ASSOCIATIVE 
PROCESSOR 

S.A.  Schuster,  E.A.  Ozkarahan,  and  K.C.  Smith, 

February  1976  [Proceedings  National  Computer 
Conference  1976,  v.45,  pp. 055-862] 

CSRG-65  PERFORMANCE  EVALUATION  OF  A  RELATIONAL  ASSOCIATIVE 
PROCESSOR 

E.A.  Ozkarahan,  S.A.  Schuster,  and  K.C.  Sevcik, 

February  1976  [ACM  Transactions  on  Database 
Systems,  v.l,  n:4,  December  1976] 

CSRG-66  EDITING  COMPUTER  ANIMATED  FILM 
Michael  D.  Tilson,  February  1976 
[M.Sc.  Thesis,  DCS,  1975] 

CSRG-67  A  DIAGRAMMATIC  APPROACH  TO  PROGRAMMING  LANGUAGE 
SEMANTICS 

James  R.  Cordy,  March  1976 
[M.Sc.  Thesis,  DCS,  1976] 

*  CSRG-68  A  SYNTHETIC  ENGLISH  QUERY  LANGUAGE  FOR  A  RELATIONAL 

ASSOCIATIVE  PROCESSOR 

L.  Kerschberg,  E.A.  Ozkarahan,  and  J.E.S.  Pacheco, 

April  1976 

CSRG-69  AN  ANNOTATED  BIBLIOGRAPHY  ON  COMPUTER  PROGRAM 
ENGINEERING 

D.  Barnard  and  D.  Thompson  (eds.),  Fourth  Edition, 

May  1976 

*  CSRG-70  A  TAXONOMY  OF  DATA  MODELS 

L.  Kerschberg,  A.  Klug,  and  D.Tsichritzis,  May  1976 
[Proceedings  Very  Large  Data  Base  Conference,  1976] 

*  CSRG-71  OPTIMIZATION  FEATURES  FOR  THE  ARCHITECTURE  OF  A 

DATA  BASE  MACHINE 

E. A.  Ozkarahan  and  K.C.  Sevcik,  May  1976 

[ACM  Transactions  of  Database  Systems,  v.2,  n.4,  December  1977] 

*  CSRG-72  THE  RELATIONAL.  DATA  BASE  SYSTEM  OMEGA  -  PROGRESS  REPORT 

H.A.  Schmid  (ed.),  P.A.  Bernstein  (ed.),  B.  Arlow, 

R.  Baker  and  S.  Pozgaj,  July  1976 
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CSRG-73  AN  ALGORITHMIC  APPROACH  TO  NORMALIZATION  OF 
RELATIONAL  DATA  BASE  SCHEMAS 
P.A.  Bernstein  and  C.  BeerL,  September  1976 

*  CSRG-74  A  HIGH-LEVEL  MACHINE-ORIENTED  ASSEMBLER  LANGUAGE 
FOR  A  DATA  BASE  MACHINE 

E.A.  Ozkarahan  and  S.A.  Schuster,  October  1976 

CSRG-75  DO  CONSIDERED  OD:  A  CONTRIBUTION  TO  THE  PROGRAMMING 
CALCULUS 

Eric  C.R.  Hehner,  November  1976 
Acta  Informatica  to  appear  1979 

CSRG-76  SOFTWARE  HUT:  A  COMPUTER  PROGRAM  ENGINEERING 
PROJECT  IN  THE  FORM  OF  A  GAME 
J.J.  Horning  and  D.B.  Wortman,  November  1976 
[IEEE  Transactions  on  Software  Engineering,  v.SE-3,  n.4,  July  1977] 

CSRG-77  A  SHORT  STUDY  OF  PROGRAM  AND  MEMORY  POLICY  BEHAVIOUR 
G.  Scott  Graham,  January  1977 

CSRG-78  A  PANACHE  OF  DBMS  IDEAS 

D.  Tsichritzis  (ed.),  February  1977 

CSRG-79  THE  DESIGN  AND  IMPLEMENTATION  OF  AN  ADVANCED  LALR 
PARSE  TABLE  CONSTRUCTOR 
David  H.  Thompson,  April  1977 
[M.Sc.  Thesis,  DCS,  1976] 

CSRG-80  AN  ANNOTATED  BIBLIOGRAPHY  ON  COMPUTER  PROGRAM 
ENGINEERING 

D.  Barnard  (ed.).  Fifth  Edition,  May  1977 

CSRG-B1  PROGRAMMING  METHODOLOGY:  AN  ANNOTATED  BIBLIOGRAPHY 
FOR  IFIP  WORKING  GROUP  2.3 

Sol  J.  Greenspan  and  J.J.  Horning  (eds.),  First  Edition,  May  1977 
CSRG-82  NOTES  ON  EUCLID 

edited  by  W.  David  Elliot  and  David  T.  Barnard,  August  1977 

CSRG-83  TOPICS  IN  QUEUEING  NETWORK  MODELING 
edited  by  G.  Scott  Graham,  July  1977 

CSRG-84  TOWARD  PROGRAM  ILLUSTRATION 

Edward  Yarwood,  September  1977 
[M.Sc.  Thesis,  DCS,  1974] 

CSRG-85  CHARACTERIZING  SERVICE  TIME  AND  RESPONSE  TIME 

DISTRIBUTIONS  IN  QUEUEING  NETWORK  MODELS  OF  COMPUTER 
SYSTEMS 

Edward  D.  Lazowska,  September  1977 
[Ph.D.  Thesis,  DCS,  1977] 
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CSRG-86  MEASUREMENTS  OF  COMPUTER  SYSTEMS  FOR  QUEUEING 
NETWORK  MODELS 
Martin  G.  Kienzle,  October  1977 

[M.Sc.  Thesis,  DCS,  1977;  Proc.  Int.  Symp.  on  Modelling  and  Performance 
Evaluation  of  Computer  Systems,  Vienna,  1979] 

CSRG-87  ’OLGA’  LANGUAGE  REFERENCE  MANUAL 

B.  Abourbih,  H.  Trickey,  D.M.  Lewis,  E.S.  Lee, 

P.I.P.  Boulton,  November  1977 

CSRG-88  USING  A  GRAMMATICAL  FORMALISM  AS  A  PROGRAMMING  LANGUAGE 
Brad  A.  Silverberg,  January  1978 
[M.Sc.  Thesis,  DCS,  1978] 

CSRG-89  ON  THE  IMPLEMENTATION  OF  RELATIONS:  A  KEY  TO  EFFICIENCY 
Joachim  W.  Schmidt,  January  1978 

CSRG-90  DATA  BASE  MANAGEMENT  SYSTEM  USER  PERFORMANCE 
Frederick  H.  Lochovsky,  April  1978 
[Ph.D.  Thesis,  DCS,  1978] 

CSRG-91  SPECIFICATION  AND  VERIFICATION  OF  DATA  BASE 
SEMANTIC  INTEGRITY 
Michael  Lawrence  Brodie,  April  1978 
[Ph.D.  Thesis,  DCS,  1978] 

CSRG-92  STRUCTURED  SOUND  SYNTHESIS  PROJECT  (SSSP): 

AN  INTRODUCTION 

by  William  Buxton.  Guy  Fedorkow,  with  Ronald  Baecker, 

Gustav  Ciamaga,  Leslie  Mezei  andK.C.  Smith,  June  1978 

CSRG-93  A  DEVICE-INDEPENDENT, GENERAL-PURPOSE  GRAPHICS  SYSTEM 
IN  A  MINICOMPUTER  TIME-SHARING  ENVIRONMENT 
William  T.  Reeves,  August  1978 
[M.Sc.  Thesis,  DCS,  1976] 

CSRG-94  ON  THE  AXIOMATIC  VERIFICATION  OF 
CONCURRENT  ALGORITHMS 
Christian  Lengauer,  August  1978 
[M.Sc.  Thesis,  DCS,  1978] 

CSRG-95  PISA:  A  PROGRAMMING  SYSTEM  FOR  INTERACTIVE 
PRODUCTION  OF  APPLICATION  SOFTWARE 
Rudolf  Marty,  August  1978 

CSRG-96  ADAPTIVE  MICROPROGRAMMING  AND  PROCESSOR  MODELING 
Walter  G.  Rosocha 
[Ph.D.  Thesis,  EE,  August  1978] 

CSRG-97  DESIGN  ISSUES  IN  THE  FOUNDATION  OF  A  COMPUTER-BASED 
TOOL  FOR  MUSIC  COMPOSITION 
William  Buxton 

[M.Sc.  Thesis,  CSRG,  October  1978] 
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CSRG-98  THEORY  OF  DATABASE  MAPPINGS 
Anthony  C.  Klug 

[Ph.D.  Thesis,  DCS,  December  1978] 

CSRG-99  HIERARCHICAL  COROUTINES:  A  MECHANISM  FOR  IMPROVED 
PROGRAM  STRUCTURE 
Leonard  I.  Vanek,  February  1979 

CSRG-100  TOPICS  IN  PERFORMANCE  EVALUATION 
G.  Scott  Graham  (ed.),  July  1979 


